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. 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
