These seem like separate problems that should be solved in different places.
2 and 3 seem like they should be implemented at the JCA level. For 2, when the connection is accessed, check to see if the current thread is associated with a transaction, if so enlist the connection with the transaction. For 3, this should also be handled by JCA. If a connection is obtained while within the context of a tx a Tx synchronization should be used to automatically close/release the connection in afterComplete. You shouldn't have to use EJB to get this automatic connection closing. If the connection has already been associated, then there is no need to register this synchronization. Is the TX still associated with the thread in Synchronization.afterComplete? If so, if somebody calls getConnection within afterComplete, the JCA impl should check to see if the current TX is committed, if so, do not enlist the connection with the TX and treat it as if it was dissassociated. One other thing on #3. I think it should also allocate an Exception when getConnection() is called. That way, if you as a developer want to find out exactly where a connection was leaked, you can find out by printing the stack trace of all places getConnection() was called and not cleaned up. You cannot do this with the CCM solution currently. I don't not understand 1/4. I'll have to read the spec. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3861238#3861238 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3861238 ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
