1. There is a behavior discrepancy between JdbcConnectionPool and ResourceLimitingJdbcConnectionPool:
JdbcConnectionPool resets autocommit in get(), ResourceLimitingJdbcConnectionPool does not.
This not ressitting of autocommit by ResourceLimitingJdbcConnectionPool causes problems, since autocommit
does not get reset in connection.close() either. Once autocommit is changed in a user program,
it stays on a connection in non-default mode after connection.close(), and next user gets connection in a non-default autocommit mode.
2. When autocommit is changed from false to true, there is a side effect: connection commits transaction -
this is according to java.sql.Connection.setAutoCommit() java doc; tests confirm this.
Therefore, it would be better to reset autocommit (if needed) in a connection.close(), so that locks go away sooner.
This would follow expected behavior of connection.close() when no pool is used.
3. At least with Oracle driver, when autocommit is false and connection.close() is called, transaction gets committed.
I do not know whether this confirms to a JDBC standard, but I am prettyr sure that this behavior is lost with either ConnectionPool.
Thanks, Alex Treyger
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
