JBMESSAGING-545 - Leaks on XA transactions

[clebert.suconic]

as stated on http://jira.jboss.org/jira/browse/JBMESSAGING-545 two phase commit transactions are leaking once they are being stored on TransactionRepository and not being released.

So, summarizing the changes I'm making to fix this:

I - I'm creating a method deleteTransaction on TransactionRepository.

II - I also changed Transaction to accept a reference to TransactionRepository, as TransactionRepository is not static.

III - On commit/rollback transactionRepository.delete is being called

IV - Changed JDBCPersistenceManagerTest to perform a test on this

V - Added a property method getNumberOfRegisteredTransactions() on TransactionRepository what is meant to be used only by tests. (I could use reflection on a private field for this, but I thought it was much cleaner to just add the property field. I could change this if someone doesn't like the exposed property)


Clebert Suconic

[timfox]

So, summarizing the changes I'm making to fix this:

I - I'm creating a method deleteTransaction on TransactionRepository.

II - I also changed Transaction to accept a reference to TransactionRepository, as TransactionRepository is not static.

Sounds good

III - On commit/rollback transactionRepository.delete is being called

Fine. Make sure this is done at the end of the processing and not in a finally block - we don't want to remove the tx if it fails (the tx mgr can retry)

IV - Changed JDBCPersistenceManagerTest to perform a test on this

V - Added a property method getNumberOfRegisteredTransactions() on TransactionRepository what is meant to be used only by tests. (I could use reflection on a private field for this, but I thought it was much cleaner to just add the property field. I could change this if someone doesn't like the exposed property)

Fine.

Also we need to make sure we return ok if a commit request comes in for a 2pc transaction and it isn't in the map.

There is a second part of this tasks which involves looking in the database if a request comes in for a transaction and it isn't in the map - but it's probably best to wait for Madhu to integrate his XA recovery work since you will need to re-use some of that.

[clebert.suconic]

For III this is being done at the end of Commit/Rollback (not a finally block).


Also, deleteTransaction is double checking for the state of the transaction. If you try to delete a transaction which is not in COMMITED or ROLLEDBACK state it will throw an exception. I wanted to have this double check since I knew this constraint.