Hey
> available. Why? Do XADataSource implementations from database
> vendors has their own garbage collectors?
> I don't think so.
XADataSource implementations *should* let the pool know when the connection
has failed.
> Or, maybe they hide actual Connections, ResultSets, etc. and put
> the actual Connections back to the pool after each method invocation?
> Impossible: AFAIK, Rickard didn't work neither in Sybase, nor in
> Oracle :-)
Uhm, correct... so..? 8-)
> Assume that a Connection instance was got in the bean method and
> then was not closed due to error, i.e. it wasn't assigned to
> an instance field. I would expect that in this case JVM Garbage
> Collector would collect the Connection instance and call finalize()
> that in turn would call close().
finalize() doesn't seem to be implemented in the ConnectionInPool wrapper.
Could this be the easy fix to do?
> I am not sure, but it seems to me that it is not true, since
> the errors of this kind really cause the exhaustion of Connections.
> Maybe the reference to the Connection instance is kept somewhere else?
Nope, that's it (i.e. the ConnectionInPool wrapper).
> Can anybody explain me this?
> Assume, that I am right and some reference remains.
> Maybe, the problem would be solved if all such referenced was replaced
> by WeakReferences (and HashMaps by WeakHashMaps).
Then we would essentially be back to the problem of "overhead per call" as
outlined by Aaron since we have to make sure that a call invocation actually
has a connection to work with.
> Now assume that this is impossible, some strong reference is needed.
> Then let's wrap the Connection with an individual proxy object for
> each bean and in finalize() method of the proxy object call close()
> for the underlying Connection.
+1
/Rickard
