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.
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.
Two phase Commit: Committing the transaction in two phases disassociates the durable subscriber from the distributed transaction.
Rolling back the transaction: Rolling back the transaction disassociates the durable subscriber from the distributed transaction.
- 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:
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:or
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.or
If the transaction cannot be committed, the transaction should be rolled back before creating the durable subscriber.
In case the transaction needs to be restarted, it should be restarted before creating the durable subscriber.