Hello Juozas! JB> Pool doe's not need locks on connection objects, "synchronized" can be used JB> for "wait/notifyAll", JB> but it needs monitor of some "global" object. Pool must never return the JB> same connection JB> for different threads, but connection can be "fail-fast" itself, JB> it is not a very big overhead for connection objects to call JB> "if(owner != Thread.currentThread()) JB> throw new ConcurrentModificationException();" JB> and to set "owner" at "getConnection" time. "owner" can be used for JB> "automagic", but I am a very big enemy for this kind of workarounds myself.
Very pleased to see your mail :) It really has nice ideas in it! But, I've got a feeling that we're talking different languages here! In fact I was discussing Ken Horn's idea that the pool could * after a connection has been grabbed but not released, for say 10 minutes * forcibly close the underlying real connection (thus freeing db server's resources) or forcibly return the real connection to the pool * emulate a database server timeout for that connection by throwing an exception on any further client's call on the wrapping connection obtained from the pool It is a way to handle reclaiming lost connections. To do this we need a monitor thread that would track connections that have not been released too long. And for it to tear the real connection away from the wrapping connection after our 10 minutes timeout we synchronization as here we have two threads (client's and monitor's) possibly competing for access to the wrapping and real connections. That's what I have been talking about :-) -Anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
