-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan,
Stefan Riegel wrote: > - Request 1 running in Thread 1 gets a db connection. > - Request 1 closes the db connection. > - The JVM switches the running thread to Thread 2 > - Request 2 running in Thread 2 gets a db connection (the same db > connection just closed by Request 1). This shouldn't happen with a good connection pool; calling Connection.close() in thread 1 returns the connection to the pool where it's state is reset and it is now "fresh". This means that it is available to other threads and its association with the previous thread is severed. A decent connection pool will hand-out Connection objects that wrap the underlying JDBC Connection object. Calling Connection.close() should null-out the underlying connection so that calling Connection.close() multiple times does nothing (as another poster pointed out: it's defined as a no-op). There should be no race conditions here with a decent DBCP. On the other hand, the last thing you should do with a JDBC connection is close it. Why are you continuing to operate on a closed connection? If it's sloppy JDBC programming, then clean up your code. It will be easier to read and therefore more maintainable. The fact that it will work better with a poorly-written DBCP is just a bonus. Like Chuck, I'm confused about your confusion. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl53+oACgkQ9CaO5/Lv0PACbgCfaCBvAGn0bZ3KCz10ca1XI0QS 468An1L0Vy4ouqTEVoaL2/qfftpA7row =DAfH -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
