Hello Juozas!
0) Preamble
AT> * after a connection has been grabbed but not released,
AT> for say 10 minutes
1)
AT> forcibly return the real connection to the pool
JB> Sorry, it is a crap and needs no discussions.
Agreed, Serge's note that the connection may be for instance
in mid-transaction has especially convinced me it's crap.
2)
AT> * forcibly close the underlying real connection
AT> * emulate a database server timeout for that connection by
AT> throwing an exception on any further client's call on
AT> the wrapping connection obtained from the pool
JB> "throwing an exception" ... needs no synchronization
err.. it does. If the eviction thread finds that a connection
has been borrowed too long then it should set up a flag on this
connection signalling that the next time a client invokes an
operation on this connection he will get an exception.
But to make sure that client's thread sees this flag we need
synchronization
JB> I understand it and I see meaning in the last option only
JB> "throwing an exception"
What's your opinion about forcibly closing the connection
at all? Might make sense if the license really limits the
number of open connections. But I feel somewhat doubtful
about this...
3)
JB> I will be very happy if nobody will add more workarounds to DBCP.
Just digging to the bottom of where we could get if we chose one
way or other.
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|