-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Carl,
A late reply, but I believe you have some problems with your code.
Mark's comments about Tomcat-pool indicate that certain sloppy
resource-management activities may leave resources open on the server,
and I'm fairly sure that, given the code you have here, there are
likely resource issues in other places, too.
Keep reading for some commentary.
On 11/19/13, 8:32 AM, Carl Boberg wrote:
> JDBC: I see the weird behaviour and my DBA is angry <Resource
> name="database1" auth="Container" maxActive="50" maxIdle="10"
> minIdle="2" initialSize="0" username="'''''" password="'''''"
> driverClassName="com.inet.tds.TdsDriver"
> type="javax.sql.DataSource"
> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> defaultTransactionIsolation="READ_UNCOMMITTED"
Just curious: under what conditions do you want to use
READ_UNCOMMITTED? That would seem to be more appropriate for a
particular set of queries and not the application-wide default.
> defaultAutoCommit="true"
> url="jdbc:inetdae7://devdb12:1433/database1_dev"
> testOnBorrow="true" validationQuery="SELECT 1"
> timeBetweenEvictionRunsMillis="10000" removeAbandoned="true"
> removeAbandonedTimeout="600" maxWait="10000"/>
>
>
> The behaviour applies to ALL queries/statements from the
> application.
>
> I have here an example of the way we close from the application,
> (the devs have named it dispose). From my untrained non java dev
> eye we do not seem to be doing statement.Close(); and Im curious if
> that might be the issue? If so, why does DBCP handle it nicely and
> not JDBC?
>
>
> public void dispose() {
>
> if (connection != null) {
>
> try { if (!connection.isClosed()) {
>
> // If autoCommit is false, we are most likely using transactions. A
> rollback will end the transaction // properly even if a pool treats
> all actual connections to the db as single long transactions. //
> Examine the connection directly instead of relying on
> ConnectionManager attribute. if (ROLLBACK_ON_CLOSE &&
> !connection.getAutoCommit()) { connection.rollback(); }
If you don't have try/catch around the connection.rollback() call, you
run the risk of leaking connections. If you leak a connection in this
dispose() method, you should be getting a) an exception logged from
your own code here:
>
> // Close the connection connection.close(); if
> (traceOpenedConnections) { timeConnectionClosed =
> System.currentTimeMillis(); } }
>
> } catch (java.sql.SQLException sqle) { sqle.printStackTrace(); }
... and b) an "abandoned" log from Tomcat-pool 5 minutes later
(removeAbandonedTimeout=600).
> this.connection = null; }
If you have an object that is retaining a reference to a Connection
and the rollback fails, you won't clear this reference. If the
connection-wrapping object is not disposed, it might be re-used and
the connection either re-used or replaced with another checkout from
the pool.
Are you always sure to call dispose from a catch block after your JDBC
calls have completed?
> // Deregister this ConnectionManger if (traceOpenedConnections) {
> deregister(this); }
In the event that the Connection is indeed leaked, here you run the
risk of another resource leak in your application: presumably you are
tracking Connection objects somewhere, and this call removed that
stored reference. If the rollback fails, you won't de-register your
Connection and, even if removeAbandoned is working properly, those
Connection objects will remain in memory indefinitely and never be
cleaned-up.
I wrote a piece a long time ago about proper JDBC resource management.
I recommend that you read it as well:
http://blog.christopherschultz.net/index.php/2009/03/16/properly-handling-pooled-jdbc-connections/
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSjLZ6AAoJEBzwKT+lPKRYL0cP/0F9nT8tJlvybVyII/cjXOGY
P6TgUUOx79tO/Jw8Q6nbLP0x9yrqD6KyKVnJqlVPaj4055tDJoSa7IZqUYNNN7WX
qZcUphI8AeqFC6php8+sofr2Qq1skYFcgiL5xFmdNvGTnfWFVluH1NjUrI6udMol
w+5dy418xGnQKxEODLigGC1tJk+1M4q/gFjbj3NhxW6gbzSnlm+Nm+96ZD+q+wU6
UPcP7kZQVol5npAW2st8ki8bbJTLXF7P8ku+vGRQ8e2GvEWXOScrtOVxu0KrS015
DZvFAIPefIjGe7XxHjo7TlfSNymBcZ7y5j5RaN544uwEIr3Yu1dJ3au5HV48u8dO
tTEPjMRbGNTqECjjG/eVPohq9SHefWXMYXJCQjbIAnCyO0h7/HQVks1i3sT3doTt
b86wIiE94iFXjuz2rTKXR2jsrcOqzPkHoTL0NvkV5wpHsagmIjynKUDb2NjiSjCc
6GFom7ZSF8IYLKdIuT7qaVriYj1FrCCNCiW+giNJGeO7yrRoPiZdQ+NAxaLwpIum
l2WUh8JIoGE7v20HXXRFjOrY+iYuZQOu+vrlCah31SpSz291MirB/lZguGR2Yqfg
AgKdxHySaOhPOXDDRlHc+6TKtACWKeIsnbZxtqrrZGWYVNLGwoTofWoJc70fPW1v
l7s5HBNVhlIWyvKg49XV
=ptL4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
