The two cases i seen the abort() helped, since it closes the socket without synchronize and the socket close will unblock the read.
But you need to be careful not to call any other blocking method first (i remeber rollback, Statement close and even isOpen (if i recall correctly) have been problematic) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Phil Steitz <phil.ste...@gmail.com> Gesendet: Friday, September 4, 2020 1:06:23 AM An: dev@commons.apache.org <dev@commons.apache.org> Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned connections? 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
