You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Anton Tagunov <at...@mail.cnt.ru> on 2003/06/30 15:23:34 UTC
Re[4]: DBCP status?
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Re[6]: DBCP status?
Posted by 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
Re[6]: DBCP status?
Posted by 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[4]: DBCP status?
Posted by Juozas Baliuka <ba...@mwm.lt>.
> 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
Sorry, it is a crap and needs no discussions.
> * 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
I understand it and I see meaning in the last option only "throwing an
exception", it needs no synchronization.
I will be very happy if nobody will add more workarounds to DBCP.
> That's what I have been talking about :-)
>
> -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