[jbossts-issues] [JBoss JIRA] Commented: (JBTM-465) Consider allowing JDBCImple to manage connection lifecycles
Mauro Molinari (JIRA)
jira-events at lists.jboss.org
Thu Feb 25 10:59:11 EST 2010
[ https://jira.jboss.org/jira/browse/JBTM-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12516673#action_12516673 ]
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 restart.
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 phases.
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 com.arjuna.ats.internal.arjuna.objectstore.JDBCImple.write_state(Uid, String, 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 com.arjuna.ats.internal.arjuna.objectstore.jdbc.h2_driver.write_state(Uid, String, 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
> Key: JBTM-465
> URL: https://jira.jboss.org/jira/browse/JBTM-465
> 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 returns.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbossts-issues