-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Wes,
On 8/18/14, 1:05 PM, Wes Clark wrote: > 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. Won't this happen automatically? If the network connection dies, the server should auto-rollback the transaction. The JDBC connection will fail due to the same reason and the pool will re-establish a new Connection. Are you sure you have to manage this yourself? > 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. This won't catch intermittent network errors, which seems like the only really valid use case for you. - -chris > -----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 > > 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 > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJT816FAAoJEBzwKT+lPKRYnwAP/1jUCMUMcjLWJ1h56qCqY3R0 x2OYgMhC9zyy6tpQDvlvDVBjNQA2ioED7CDyVytmCQg2m6C11YC/loitQrGGfq/S Q4KwXEXKlPLsmyYRF1LeE6CYzu0loj1BtiYet9sQuDPKIGEnGxTgS1/0jfiQurKC 57KCDUO3DOeXsnXy8a5lWyrLHGYB1VGa6oRGLoiRcDEKKHKKc0hW+6xOL2LjAkVH EtS1Q9EpO4EzbXXDnCuoWD4jkZ3r6Csjz6aHRUdXO0/fqZKNQDpJnLASfQMVoe73 8AkzHHl2X4H/n7loReWw66BysnHtc6kX9M6sK/xjVUHtZJBYGMIBUQ4gbTymvN1v au1Re28wwaYFrVPGW997X+NAuRqhff9mV4Xfk3yVREo+RVnCZWzsAYW9M1HBJ5/m hjki8uglRfS3befn9ph13igtFcD+df8kXMylL0/JldBbxf+gNAYdWx40/oClZ9PV e3AFLClN3i2tJh/0/+3Z2eTVss+F+eNkAVqQkmpO/uQ0xtOO9EsNUOdYFuqndnTK VgQCGrJXn1MQ2bW6i5H+Y8JXiRmUSPR2K169AGYBBu8yY8bWcjTmOUJ5xVGrm8mA sZ5xUPYQQpHDBP5p03xxi+OtWjMrZjZB6t1TZK0enAv3ni5XFoml7sNukHWhqg4h bgMrFIWeOUz3QQLoyIm2 =GLlP -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
