The second beta of BTM 1.3 is now ready.
The release can be downloaded here:
and the Maven2 artifacts and POM have been published here:
Here are the updated release notes:
* BTM-4 Implement incremental recovery
* BTM-7 Resource password is not decrypted when using the API
* BTM-8 Durable subscribers cannot participate in XA
* BTM-9 BitronixTransactionManager JNDI reference throws NPE on toString()
* BTM-10 Race condition in connection pools when lazily initialized
* BTM-11 Implement an embedded JNDI provider that allows to retrieve the TM and configured resources in a more standard way
* BTM-12 add maven support
* BTM-13 Implement ordering of XAResource during 2PC execution
* BTM-14 Need the ability to have BTM invoke specific methods on JDBC connection upon return to the pool
* BTM-17 Set tx status to marked_rollback on timeout
* Dropped all deprecated classes and methods.
* Shutdown hook is not registered anymore when the TM starts up. It is now mandatory to shut it down manually.
* Fixed incorrect transaction manager startup while using pools when BTM is not started.
* Moved CryptoEngine to bitronix.tm.utils, kept bitronix.tm.internal.CryptoEngine but deprecated it.
* Resource Loader cannot bind to JNDI anymore (no more needed, see: BTM-11), this obsoletes bitronix.tm.resource.bind property.
* Transaction timeout logic has been rationalized, this obsoletes bitronix.tm.timer.transactionRetryInterval property.
* Lowered statement cache overhead when it is disabled.
* Fixed bug in the double LRC enlistment check that prevented safe cases from working.
* Upgraded JTA and JMS jars to the latest 1.4-compiled version.
Incremental recovery required a change in the Disk Journal's log format. Compatibility with older format (1.2 and below) has been maintained but journals created by BTM 1.3 cannot be read by older versions.
It is strongly recommended for anyone testing BTM 1.3 beta 1 or any other snapshot 1.3 release to upgrade to this version to make sure the latest code changes did not break anything and that all fixes for reported errors haven't been left out by accident.
If the testing phase of this version gives good result and no new serious issue is discovered this will be the latest version before the 1.3 final release.
As usual, please report any bug / question / remark / extra wish you might have here.
The BTM Team
I finally found some time to test this new version of BTM. But I have one question : is there something needed to activate incremental recovery ? I tried to start my application (which starts BTM) with the JMS provider off and it fails the same way than version 1.2 (see the logs below) :
2008-05-27 15:23:11,973 INFO [bitronix.tm.BitronixTransactionManager] - Bitronix Transaction Manager version 1.3-beta2
2008-05-27 15:23:11,973 INFO [bitronix.tm.Configuration] - JVM unique ID: <matrix-btm>
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'BitronixTransactionManager' defined in ServletContext resource [/WEB-INF/dataAccessContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: Factory method [public static synchronized bitronix.tm.BitronixTransactionManager bitronix.tm.TransactionManagerServices.getTransactionManager()] threw exception; nested exception is bitronix.tm.utils.InitializationException: recovery failed, cannot safely start the transaction manager
Caused by: bitronix.tm.recovery.RecoveryException: error running recovery on resource swiftmq
... 78 more
Caused by: bitronix.tm.recovery.RecoveryException: error starting recovery
... 80 more
Caused by: javax.jms.JMSException: error looking up wrapped XAConnectionFactory at plainsocket@router_mcto_dev
... 82 more
Caused by: javax.naming.NamingException: unable to connect, exception = javax.jms.JMSException: Unable to create a connection to: [[ServerEntry, hostname=localhost, port=4001]]
at com.swiftmq.jndi.v400.ContextImpl.<init>(Unknown Source)
at com.swiftmq.jndi.InitialContextFactoryImpl.getInitialContext(Unknown Source)
... 88 more
Any idea ?
I guess what you expected was the ability to register a resource and leave it inactive if recovery fails and have the TM retry it until the resource can finally be recovered and made active.
This is not what incremental recovery is about, the resources still need to be recovered when they're created. Incremental recovery just allows you to safely register them after the transaction manager started.
It is currently up to you to build that functionality. For instance, you could start BTM then create your resource. If resource initialization fails, the TM will ignore that resource so you can retry initialization later on. There is such functionality in the Resource Loader only in case you're using it.
|Free forum by Nabble||Edit this page|