commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: Re[2]: DBCP status?
Date Mon, 30 Jun 2003 13:40:31 GMT


Pool doe's not need locks on connection objects, "synchronized" can be used
for "wait/notifyAll",
but it needs monitor of some "global" object. Pool must never return the
same connection
for different threads, but connection can be "fail-fast" itself,
it is  not a very big overhead for connection objects to call
"if(owner != Thread.currentThread())
 throw new ConcurrentModificationException();"
and to set "owner" at "getConnection" time. "owner" can be used for
"automagic", but I am a very big enemy for this kind of workarounds myself.

> Hello Ken!
>
> There have been very strongly argumented opinions
> that the pool should do nothing of the sort, but
> I'd like to go to the bottom of discussing other
> alternatives too.
>
> KH> * emulates a legal timeout from the database server
>
> I have been stricken with the beauty of approach
> you have proposed, indeed its nice to emulate
> a server timeout :-))
>
> I still have one reservation: its synchronization.
> Does this proposition mean that we have to make
> all the normal operations on the connections
> synchronized?
>
> I'm afraid something nasty may happen if while
> the user is executing a lengthy query another
> thread close()-s the connection.
>
> (I'm not concerned that we shall kill legitimate
> client operation - after all the client should
> have specified a longer timeout then, I'm concerned
> that we may upset the driver or something.)
>
> Another synchronization issue is that theoretically
> w/o a synchronization the fact that we have
> called close() on the connection is not guaranteed
> to be propagated to the other thread that is probably
> holding the connection. Unless the db driver does
> synchronization somewhere underneath of course.
>
> What do you think of this synchronization overhead?
> Negligible?
>
> - 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


Mime
View raw message