On 9/3/20 3:02 PM, Bernd Eckenfels wrote:
The issues I have seen are not a/b "deadlocks", they are "just" endless locks -
the close is waiting for a read to finish (since both synchronize on the connection). If the
asumption is a pool timer can in the background cancel a read - it can't, at least on Oracle thin
or jtds.
The cause can be softened by using read timeouts and/or keepalive, but both is
not the default and can block the pool for minutes, still.
The question is would using abort instead of close work better in some
of the abandoned connection scenarios. IIUC the contract correctly, at
least the pool thread will not be blocked in these scenarios if we move
to this for that use case. Note that dbcp/pool can be configured to
remove abandoned connections on borrow as well as maintenance, so
blocking in the former case blocks the pool client.
Phil
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: Mark Thomas <ma...@apache.org>
Gesendet: Thursday, September 3, 2020 11:44:52 AM
An: dev@commons.apache.org <dev@commons.apache.org>
Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned connections?
On 31/08/2020 01:05, Phil Steitz wrote:
<snip/>
If others agree it is a good idea for dbcp, I can do it. I can see the
argument that its better to stay with close() even for abandoned and I
have not been able to get the deadlock to happen, so I would like to
wait a bit and allow others to weigh in. Similarly for pool, I would
like to get more community feedback before adding to the interface.
Hmm.
On one hand if the driver deadlocks I don't see how that can be anything
other than a driver bug. If multiple code paths obtain multiple locks
then those code paths must always obtain those locks in the same order.
Anything else is a bug that is likely to result in a deadlock in a
multithreaded environment.
On the other hand, it could be argued that the situation only arises
when an application doesn't correctly return connections to the pool
and/or keeps them for too long and/or doesn't configure the pool
correctly for their usage pattern.
The approach of adding
PooledObjectFactory.destroyObject(PooledObject,CloseMode)
where CloseMode is an Enum with two values looks reasonable to me.
I do agree that abort() should only be used in the case of abandoned
connections.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
