Message-ID: <1673519180.298682.1368937351383.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_298681_1238349351.1368937351382" ------=_Part_298681_1238349351.1368937351382 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
There is one caveat with = Last Resource Commit. There is a small chance that a transaction ends up wi= th inconsistent results across participating resources if BTM crashes while= a transaction is in-flight. The chance is small but it exists so be carefu= l when using that feature. This is in no way a limitation of BTM b= ut of the concept itself.
Please note that if you only intend to run transactions against a single= JMS server using Last Resource Commit this scenario is 100% safe, otherwis= e not.
In theory, only JMS servers supporting XA and providing a
s.XAConnectionFactory implementation can be used with transaction ma=
nagers. In practice, there is a way around this limitation.
The Last Resource Commit optimization (sometimes referred to as Last Res= ource Gambit or Last Agent optimization) allows a single non-XA resource (J= MS server or database) to participate in a XA transaction by cleverly order= ing the resources.
|Maximum one non-XA resource|
Ther= e can be at most one resource emulating XA with Last Resource Commit partic= ipating in a transaction. If it happens that you're trying to use a second = emulating resource while one has already been used, BTM will throw an excep= tion. Again, this is not a limitation of BTM but of the concept itself.=
To enable it, you just have to create a
code> using the bitronix.tm.resource.jms.lrc.LrcXAConnectionFactory as the implementation.
Here's an example of code configuring a ActiveMQ datasource:
and the same example viewed as a Resource Loader configuration