Re[6]: DBCP status?

[Anton Tagunov <at...@mail.cnt.ru>]

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

Re: Re[6]: DBCP status?

[Juozas Baliuka <ba...@mwm.lt>]

Hi,
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" <at...@mail.cnt.ru>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org