Limitations of XA Implementation of FioranoMQ

XAResource's Transaction timeout() APIs and forget() APIs are not supported in this release.

A durable subscriber can be associated with only one distributed transaction at any point of time. It can be associated with the next transaction only when it is disassociated with the previous transaction. The durable subscriber gets associated with the transaction when the xaResource object, created from the same session object as the durableSubscriber, starts a new transaction. This association ends when the resource object performs a commitrollback on the transaction that is started.

The following code snippet displays the point at which the association of the durable subscriber ends with the transaction.

CODE

// Get the topic session object
TopicSession ts = xats.getTopicSession();
// create a durable subscriber. This subscriber is not associated with 
// the distributed transaction as the distributed transaction has not started yet.
TopicSubscriber subscriber = ts.createDurableSubscriber(topic,"clientId");
// get the xaResource object
XAResource xaresource = xats.getXAResource();
// start the resource Object. During this call, above durable subscriber gets 
// associated with the transaction. 
xaresource.start(xid,XAResource.TMNOFLAGS);
Applications perform some work here: 
// end the resource object. The association does not end when the resource ends. 
xaresource.end(xid,XAResource.TMSUCCESS);
// prepare the resource object
xaresource.prepare(xid);
// commit the resource object. The association ends when the resource object gets 
// committed. The association ends when the resource objects rollbacks.
xaresource.commit(xid, false);

The methods with which a durable subscriber can be disassociated from the distributed transaction are:

Single phase commit: Committing the transaction in a single phase disassociates the durable subscriber from the distributed transaction.
CODE
```
xaresource.commit(xid, true);
```
Two phase Commit: Committing the transaction in two phases disassociates the durable subscriber from the distributed transaction.
CODE
```
xaresource.prepare(xid);
xaresource.commit(xid, false);
```
Rolling back the transaction: Rolling back the transaction disassociates the durable subscriber from the distributed transaction.
CODE
```
xaresource.rollback(xid);
```
Invalid attempts: The association of the durable subscriber does not end when the resource object ends the distributed transaction. As explained above, the association ends only when the transactions commit/rollbacks the transaction that has started. If a durable subscriber is associated with a distributed transaction that has ended, performing any of the following functions leads to the throwing of an exception by the FioranoMQ server.

Start transaction: FioranoMQ Server throws an exception in case an attempt is made to start a new transaction when the previously started transaction has not committed/rolled back yet. The following code snippet displays the above:

CODE

// create a durable subscriber. 
// TopicSubscriber subscriber = ts.createDurableSubscriber(topic,"clientId");
// start a resource Object. 
xaresource.start(xid,XAResource.TMNOFLAGS);
..
// end the resource object. 
xaresource.end(xid,XAResource.TMSUCCESS);
// Attempt to start a different transaction leads to an exception
xaresource.start(xid2,XAResource.TMNOFLAGS);

The application provider is advised to commit or rollback the transactions that have ended, before starting new ones.
The following code snippet explains the workaround to the mentioned problem:

CODE

// get the resource object
xaresource = xats.getResource();
The transaction should be committed before creating the durable subscriber. The transaction can be committed either in a single phase or in two phases. 
xaresource.prepare(xid);
xaresource.commit(xid,false);

or

CODE

xaresource.commit(xid,true);
If the transaction cannot be committed, the transaction should be rolled back before creating the durable subscriber. 
xaresource.rollback(xid);

Restart the application: FioranoMQ retains the state of all the transactions that have ended or that are prepared. If an application crashes after ending a transaction, it can restart/prepare/commit/rollback the transaction. If an application, where a durable subscriber is associated with the ended transaction, crashes, any attempt to use the subscriber in non-xa transactions or in any other transaction leads to an exception.

An example: A durable subscriber is associated with a distributed transaction; xid. The application crashes after ending the transaction xid. When the application restarts, the following sequence leads to an exception:

Subscriber creation without starting the transaction: An attempt to create a subscriber, without starting the transaction those ending leads to an exception thrown by the JMS server.
CODE
```
// get the resource object
xaresource = xats.getResource();
// attempting to create a durable subscriber, without starting the transaction leads to 
//an exception.
dsubscriber = ts.createDurableSubscriber(topic, "subId");
It is recommended that the application provider should commit/rollback/restart the ended distributed transaction before creating the durable subscriber. 
// get the resource object
xaresource = xats.getResource();
The transaction should be committed before creating the durable subscriber. The transaction can be committed either in a single phase or in two phases. 
xaresource.prepare(xid);
xaresource.commit(xid,false);
```
or
CODE
```
xaresource.commit(xid,true);
```
If the transaction cannot be committed, the transaction should be rolled back before creating the durable subscriber.
CODE
```
xaresource.rollback(xid);
```
In case the transaction needs to be restarted, it should be restarted before creating the durable subscriber.
CODE
```
xaresource.start(xid, XAResource.TMJOIN);
// Creating the durable subscriber is possible after this: dsubscriber = ts.createDurableSubscriber(topic, "subId");
// attempting to create a durable subscriber, without starting the transaction leads to an exception.
dsubscriber = ts.createDurableSubscriber(topic, "subId");
Distributed Transactions do not work for unified connections.\
```
If a transaction is in the start phase, then it will rollback automatically when the server terminates.