commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <>
Subject Re: Re[6]: DBCP status?
Date Tue, 01 Jul 2003 11:25:52 GMT

I think pool must do one thing good.
You are talking about resource management, it is out of [dbcp] scope, but
can be a subject for a new project in sandbox. Resource/Transaction manager
is very clear thing,
It must do one thing good too and "close/commit/rollback" must throw
UnsupportedOperationException in managed connection (if app tries to manage
resource itself contract is broken).
 It seems JCA is about this stuff, but [dbcp] is low level component and
contract is very clear "close" connection yourself and fail if
contract is broken.

----- Original Message -----
From: "Anton Tagunov" <>
To: "Jakarta Commons Developers List" <>
Sent: Tuesday, July 01, 2003 9:52 AM
Subject: Re[6]: DBCP status?

> 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:
> For additional commands, e-mail:

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

View raw message