Message-ID: <1035281301.3392.1369371694144.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3391_1193400897.1369371693533" ------=_Part_3391_1193400897.1369371693533 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Bitronix Transaction Manager (BTM) is a simple but complete implemen= tation of the JTA 1.0.1B API. The goal is to provide a fully working XA tra= nsaction manager that provides all services required by the JTA API while t= rying to keep the code as simple as possible for easier understanding of th= e XA semantics. This is BTM's strongest point compared to its competitors: = when something goes wrong it is much easier to figure out what to do thanks= to the great care placed in useful error reporting and logging.
BTM is a perfect choice for a project using the Spring framework and wil= ling to leverage Spring's transact= ions capabilities by using the JtaTransactionManager facade. = You can safely mix JDBC and JMS accesses in a single unified transaction wh= ile you can use Spring's JDBC or JMS Templates with very good performance a= s BTM ships with efficient pools for both resource types.
It is also possible to integrate BTM in web containers like Tomcat or Je= tty and get raw access to a JTA implementation to integrate for instance wi= th Hibernate to get automatic session context management.
BTM has proved to be stable and mature enough to be used in production b= y at least two major corporations where it has been running flawlessly (and= is still running) for months.
Currently BTM is very stable and usable. JDBC and JMS resources are work= ing pretty well and recovery after crash works plain fine thanks to the emb= edded disk journal. It has been so since the early alpha releases because t= horough testing is done before any release.
Normally, only XA aware resources can participate in global transactions= (with a special exception for JDBC) which means there are three resource t= ypes that can be used:
For JDBC, the driver must provide an implementation of the javax.sql.XADataSource interface. Plea= se note that the underlying database must also provide some support to the = driver one way or another. It is not possible to write a JDBC driver suppor= ting XA for a database that does not support it. On the other hand, it is p= ossible to write a driver that fakes XA support and this solution has been = used by some vendors.
BTM also provides a way to allow any JDBC driver to take part in a XA tr= ansaction by emulating XA with the Last Resource Commit optimization. You c= an read more about this feature in the documentation.
A list of databases that have been tested with BTM is being maintained <= a href=3D"/display/BTM/JdbcXaSupportEvaluation">here.
For JMS, your vendor must provide an implementation of the javax.jms.XAConnectionFactory int= erface. The same remark as for JDBC holds: only implementations truly suppo= rting XA (or trying to) have been considered.
A list of JMS servers that have been tested with BTM is being maintained= here.
JCA connectors could potentially be used too but BTM currently lacks sup=
port for them.