commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Tagunov <>
Subject Re[4]: DBCP status?
Date Mon, 30 Jun 2003 13:23:34 GMT
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 :-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message