One of the primary conditions for which we want to mark the connection for
death is when a rollback fails with an exception. An example of this kind of
error is a network error. We do this with:
PooledConnection pooledConnection = conn.unwrap(PooledConnection.class);
pooledConnection.setDiscarded(true);
I think I'll modify my code so that if an exception is thrown, instead of
unconditionally evicting the connection from the pool, run the validation query
right then and only evict if it fails.
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, August 12, 2014 8:28 PM
To: Tomcat Users List
Subject: Re: Question on Tomcat JDBC Connection Pool
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Wes,
On 8/12/14, 5:26 PM, Wes Clark wrote:
> (If the answer differs between Tomcat 7 and Tomcat 8, please note
> that.)
>
> When a SQL exception occurs, often the database connection will be
> broken and should be evicted from the pool.
I'm interested in what kind of SQLException you'd get that you'd consider
permanently fatal to the pooled connection. You can always rollback any
transaction you've started and failed to complete.
> In our code, we call this "marking the connection for death". We do
> this because we don't want to set the "testOnReturn" attribute to true
> to minimize the load on the database server. We set "testOnIdle"
> which will eventually find and evict stale connections, but maybe not
> fast enough for a bad connection which is returned to the pool.
>
> My question is whether the "test on return" is done on the same thread
> as the user, or on a different thread that belongs to the connection
> pool.
I haven't looked at the code, but I'd be surprised if it happens in a separate
thread. That is, I would expect that the application thread would be used.
> If the latter, we wouldn't have to catch the fact that SQL exception
> has occurred and make sure the connection is evicted from the pool,
> and maybe would be okay with the extra load on the database server as
> long as the user time is not affected.
The pool will remove the connection from itself without your intervention,
regardless of what thread does that check.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJT6ttIAAoJEBzwKT+lPKRYpn0QAK3wm+qkT/VTZ3JDsB3EqUIf
+LKOmDZ2szUgzL0VOScl0jksXzcyYIvLqt/OmmU6dKBTDuxgNO5j7rZBRFzcHfi2
c2cL3fXzUYWTS6y825cokYkX/rQJJJ2WM6QDhracFN3SIMdDO7E7YOjudbk5VEOf
QoEMLX7V1uvnR1H1JWyE9QJKIdof1oYpIeiQtDi64PmC6u+gPuLN1512ZGxZpZfV
JUvqJe4rkW+bDWiqhC5O3RE0HbsqLRn+/0YR98drIWQpTZhsymIBXfTtbm0OAFgv
oQN6JKjUPFqoFTJ/l/lGSjqICQCapgarntuPhTks9bJ9e0fK/ljwq4UXb07sxZ5T
huVGQkIkxfjBCslVPmwg9ffzcz6ZiJ9iySAoQL5IfAM7KSbIvsXNRBbGEOlJ1jWq
45CZfalqrtfOw36zFmGHgtmdXSAJJTUQxbCBQ1QXhxqT/QnJErFLXEdyH4/qm/Q6
obtCmSOgoWkiGiap3bCXsI2zWDyX3nRjncraJy04YtFH5aXTgBj/ww9dsToi0N9e
kUT3UnMFJT1A1kPKZQ5H4pd8UtbbqKALUrWZhkeceOvHY2gVXse8YPPM5fiIl/E+
guZUQp3/d45csKp/uxxUNmjB5CU8d43O9c6aV/YX5Im6slMC4xsRuFolZJwBb0uA
lZ/GiIrzyfMpmPcoyVrp
=p9Od
-----END PGP SIGNATURE-----
