Mauro Molinari commented on JBTM-465:
I'm here again regarding this issue.
As I wrote in the referenced forum topic, what I'm doing right now is to collect all
the created connections (by my JDBCAccess implementation) and shut down them on webapp
However, there's a little issue when embedding JBossTS in a stand-alone application.
In our case, this is happening when unit-testing our application code.
I'm going to explain it better.
In out unit testing framework, we do the following:
--- for every test case: ---
1. in the setup phase, initialize JBossTS
2. in the test phase, run the tested code, which uses JBossTS
3. in the tear down phase, shutdown JBossTS
Step 1. and 3. are almost the same that happen in our web application start and stop
In step 3. all the connections returned by our implementation of JDBCAccess are closed.
Now, when more than one test case is executed (so, points 1. to 3. are reiterated), during
the second, third, etc. iterations unfortunately in step 1. JBossTS does not re-create the
Object Store, so at the first attemp to connect to it, connections in
com.arjuna.ats.internal.arjuna.objectstore.JDBCImple._theConnection array are all closed
(by step 3. of the previous iterations), so any attempt to setup and execute a prepared
statement (for instance in
OutputObjectState, int, String)) fails. This is not a big problem, because
com.arjuna.ats.internal.arjuna.objectstore.JDBCImple.reconnect(int) is invoked to create a
new connection, however if you consider for instance
OutputObjectState, int, String), because the internal state of the class is not handled in
a stack-way (to handle the recursive call in the catch clause), when the outer write_state
calls terminates and calls
com.arjuna.ats.internal.arjuna.objectstore.JDBCImple.freePool(int), a warning is logged
(identified by "com.arjuna.ats.internal.arjuna.objectstore.JDBCImple_18")
because the connection has been already freed by the inner call to write_state. As I said,
this is not a real issue, but it is annoying in our use case.
Anyway, all of this could be avoided if either JDBCImple or the Object Store correctly
implemented a shutdown method. In fact, from one iteration to another the Object Store is
recycled and not recreated because even if I correctly disable the TxControl in step 3.,
in step 1. of the following iteration the TxControl is re-enabled, the
TransactionStatusManager is correctly recreated and it creates a new ActionStatusService.
However, the latter keeps on using its static field
com.arjuna.ats.arjuna.recovery.ActionStatusService._objectStore, which is initialized once
(at step 1. of the first iteration) and never disposed.
Saying it in a simple way: it would be useful to implement a correct lifecycle for the
Object Store (and for its connections, of course), bound to the TxControl one.
Consider allowing JDBCImple to manage connection lifecycles
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Resource Manager
Affects Versions: 4.5.0
Reporter: Mark Little
Assignee: Mark Little
Fix For: future
JDBCImple assumes that the JDBCAccess class manages the lifecycle of connections it
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira