A pool-related deadlock was reported recently in [1] to tomcat-user.
The OP was using a different pool, but it looks to me like the same
deadlock could happen with dbcp. The source is arguably a driver bug,
but in [2], the driver maintainer makes the good point that to avoid the
problem in [1] (and others like it) it would be better if pool
maintainers used abort instead of close to disconnect "stuck" or
abandoned connections. That makes sense to me.
To implement this in dbcp, we would need to either always use abort
instead of close when closing physical connections (a bad idea, IMO, as
it could mess up counters due to async execution and add overhead) or
modify pool to call a different factory method than destroy when
triggering close-abandoned. I think the latter makes sense and it could
be useful for other pool clients to be able to this kind of thing as well.
What I propose is that we make these change to pool:
1. Add a new method to PooledObjectFactory called "abandonObject" with
default implementation delegating to destroyObject.
2. Change the logic in removeAbandoned to call the new factory method
instead of destroyObject
And then in dbcp:
* Add implementation of abandonObject in PoolableConnectionFactory to
call abort.
wdyt?
Phil
[1]
https://lists.apache.org/thread.html/r7095d641bbc8db0a526d2d9a18684202347a747cf0e315a4a50d2001%40%3Cusers.tomcat.apache.org%3E
[2] https://bugs.mysql.com/bug.php?id=64954
