I forgot to say ... this is using JBoss v 2.4.4 with embedded Catalina v 4.0.1.
I recommend that you don't abuse the wrappers. If you want to do things like that, get a real xa driver. Is there really a situation where you wouldn't know what connection the statement/result set came from?
At this point I don't see the need to maintain a resultset wrapper to enable your code to work properly. Do you?
The answer to your first question is yes, I do have a situation where I don't know what connection the statement/result set comes from although admittedly it was more out of convenience than anything else. I have now coded around the problem and I prefer the new version anyway.
I have since tested the behaviour on Websphere 3.5 and 4.0 and the code does "work properly" there.
I'm not sure that whether the code was good or not actually matters. The fact is that it is relatively easy to destroy the connection pool using the standard JDBC API.
My personal opinion on this is that Statement.getConnection() should return the Connection that created it. Since a wrapped connection created the statement, the statement should return the wrapped connection. The same is true for a wrapped ResultSet.
More importantly than my opinion ... surely the current implementation breaks the very abstraction that JBoss is using to implement connection pooling? Ugh, too many implementations in that sentence ;-).
In principle I agree with you, however my lifetime is not infinite and I don't want to have to maintain another wrapper class with 500,000 delegating methods only one of which does anything. OK I'm exagerating a little bit;-), but I'm not convinced this is a very serious issue. Are you?
It's not an issue for me anymore but I do think it's fairly serious. After all, we are talking about closing a connection that is from a pool and never returning the connection to the pool (I presume).
Possibly more serious than depleting the pool is that when the connection is closed it performs a commit. That could be half way through a transaction! You get an exception from the container but it's too late by then - the data is corrupt.
Let's at least raise a bug for this so that it is documented and can hopefully get fixed sometime. If I get the chance I might even look into it myself.
Is the bug list on sourceforge the one to post to?
Yes, sourceforge. Please point out that you kind of have to jump through hoops to get the underlying connection, and that the workaround is to pay attention and just use the connection you started with, or get it back from the wrapped statement, and that fixing it requires a resultset wrapper.