[ https://jira.jboss.org/jira/browse/JBTM-465?page=com.atlassian.jira.plugi... ] Mauro Molinari commented on JBTM-465: ------------------------------------- A forum topic that could be useful: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202427 Mauro. -- 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

[ https://jira.jboss.org/jira/browse/JBTM-465?page=com.atlassian.jira.plugi... ] 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. -- 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

[ https://issues.jboss.org/browse/JBTM-465?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson reassigned JBTM-465: ---------------------------------- Assignee: Tom Jenkinson (was: Mark Little) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBTM-465?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson commented on JBTM-465: ------------------------------------ We should consider this in relation to https://issues.jboss.org/browse/JBTM-809 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBTM-465?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson resolved JBTM-465. -------------------------------- Fix Version/s: 5.0.0.M2 4.17.3 (was: 5.0.0.M3) Resolution: Out of Date Please can you review this in context of JBTM-1230, I think the changes we made there might have addressed your requirements -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBTM-465?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson commented on JBTM-465: ------------------------------------ Hi Mauro, Thanks for the feedback, take a look at: https://github.com/jbosstm/narayana/blob/4.17/ArjunaCore/arjuna/tests/cla... and https://github.com/jbosstm/narayana/blob/4.17/ArjunaCore/arjuna/src/test/... in particular the reference to https://github.com/jbosstm/narayana/blob/4.17/ArjunaCore/arjuna/classes/c... and https://github.com/jbosstm/narayana/blob/4.17/ArjunaCore/arjuna/classes/c.... I have tried to make JBTM-1230 as generic as possible and as you can see from the test I linked to, it does not require JNDI. Also, I can't speak for the patches before too much as JDBC Object Store was somewhat off the "hot plate" and so by the time we had chance to review them, it is possible that they didn't overlay cleanly any more. That said, if you have any further patches against https://github.com/jbosstm/narayana/ they can be raised using our pull req mechanism, automatically CI'd and are so much easier to integrate so it should be much smoother these days. You will have to forgive me as I don't know how to retrieve the list of confirmed CLA signers, but I assume you have signed: https://cla.jboss.org/ Thanks again for contributing! Tom -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira