tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Question on Tomcat JDBC Connection Pool
Date Tue, 19 Aug 2014 20:20:31 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Bertrand,

On 8/19/14, 2:23 PM, Bertrand Renuart wrote:
> 
> 
> On 19/08/14 16:26, "Christopher Schultz"
> <chris@christopherschultz.net> wrote:
>> 
>> 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?
> 
> For the pool to re-establish a new connection you have to set 
> testOnBorrow=3Dtrue, otherwise you have to wait until the next time
> the PoolCleaner kicks in (provided you have testOnIdle=true). Wes┬╣
> proposition speeds up the detection of the dead connection without
> requiring a validation on borrow.

Aah, I see. That wasn't entirely clear from the original posting, but
it makes sense given what Wes was saying.

>>> 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.
> 
> We also faced some weird jdbc drivers that forced us to drop a
> connection after some specific exceptions have occurred. If not, we
> got strange behaviour with some queries but not all (and of course
> the validation query was ok :-( Here also we followed an approach
> similar to Wes=B9 proposal.

I'm interested in which JDBC driver that affected. Can you share?


> PooledConnection pooledConnection =
> conn.unwrap(PooledConnection.class); 
> pooledConnection.setDiscarded(true);

I wonder if calling Connection.abort (from the public
java.sql.Connection API) would be a bit safer. I haven't checked the
tomcat-pool code to see if this is a no-op or if it works as desired.
If it doesn't work, it might be nice to support that kind of thing for
these cases.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJT87GOAAoJEBzwKT+lPKRY1OYP/2W6XEODiKg/t7kn83leDPUh
miOqBTJ84rv5BQP5m9HZ/a37xWmitDsQxrCMWRd885pc/dga9tfOiSjdFJsg7Z2u
rOJqiP5ItPMaTYtpDxblDV3vehC5qkSE6U4ZbiSfDpq35pgDGqTUUy5iOQqWMHA5
yQGb8IbM6uKfGAjj06iIHeRvy9l2iiyFL/DFy+XeYWttrfA3GK5h5e012DYMH0Rm
aTaDtxjoKs98ktt4oHKEdRMH8caU87rjNA6RkIjCThpXcI+gYv8pZ+Xnujot3WWO
JQkbU7lJzMS/Al/QzhUjDA+hDQz/1CUYSc9UHHohRZHp4ghO98h/rKgCADwWDFta
V6SHNmnTcnNCUlp+cF6KVhAB4IvKdApNaxmx7stjLmLPtYCCYhLDBuUOiVdwOlZ2
nAtsch1Otd6RMkEFF4yw9HKNdbuvYqqcP9IFlwO4kUfQOubD0hl4JjJiSK20DXAi
gyWKLXBSu9jHcZLMiADTPEFQrA+aB+mWL5zn+lNIVik0F7vJodidP2Gtbew1Wa6/
3FPb56X/xzMa4IdtmirHktZrz64Ky5Gf86IbWs1r1MS3W7nhpsRCgLZYHkmpUB+S
rNIHwq+2/VpUNQeAfj8AGCQw720fb539a6vsQoYiQT5euPf/zT4T8XwFvheInuE/
eAQyeZzOcJhY4w70d23H
=6Isa
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message