public C3P0PooledConnection(
Connection con,
ConnectionTester connectionTester,
boolean autoCommitOnClose,
boolean forceIgnoreUnresolvedTransactions,
ConnectionCustomizer cc,
String pdsIdt)
throws SQLException {
try {
if (cc != null) cc.onAcquire(con, pdsIdt);
} catch (Exception e) {
throw SqlUtils.toSQLException(e);
}
this.physicalConnection = con;
this.connectionTester = connectionTester;
this.autoCommitOnClose = autoCommitOnClose;
this.forceIgnoreUnresolvedTransactions = forceIgnoreUnresolvedTransactions;
this.supports_setTypeMap =
C3P0ImplUtils.supportsMethod(con, "setTypeMap", new Class[] {Map.class});
this.supports_setHoldability =
C3P0ImplUtils.supportsMethod(con, "setHoldability", new Class[] {int.class});
this.dflt_txn_isolation = con.getTransactionIsolation();
this.dflt_catalog = con.getCatalog();
this.dflt_holdability =
(supports_setHoldability ? con.getHoldability() : ResultSet.CLOSE_CURSORS_AT_COMMIT);
}
private SQLException handleMaybeFatalToPooledConnection(
Throwable t, Object proxyConnection, boolean already_closed) {
// System.err.println("handleMaybeFatalToPooledConnection()");
SQLException sqle = SqlUtils.toSQLException(t);
int status = connectionTester.statusOnException(physicalConnection, sqle);
updateConnectionStatus(status);
if (status != ConnectionTester.CONNECTION_IS_OKAY) {
if (Debug.DEBUG) {
// System.err.print(C3P0PooledConnection.this + " will no longer be pooled because
// it has been " +
// "marked invalid by the following Exception: ");
// t.printStackTrace();
logger.log(
MLevel.INFO,
C3P0PooledConnection.this
+ " will no longer be pooled because it has been marked invalid by an Exception.",
t);
}
invalidatingException = sqle;
/*
------
A users have complained that SQLExceptions ought not close their Connections underneath
them under any circumstance. Signalling the Connection error after updating the Connection
status should be sufficient from the pool's perspective, because the PooledConnection
will be marked broken by the pool and will be destroyed on checkin. I think actually
close()ing the Connection when it appears to be broken rather than waiting for users
to close() it themselves is overly aggressive, so I'm commenting the old behavior out.
The only potential downside to this approach is that users who do not close() in a finally
clause properly might see their close()es skipped by exceptions that previously would
have led to automatic close(). But relying on the automatic close() was never reliable
(since it only ever happened when c3p0 determined a Connection to be absolutely broken),
and is generally speaking a client error that c3p0 ought not be responsible for dealing
with. I think it's right to leave this out. -- swaldman 2004-12-09
------
if (! already_closed )
doSilentClose( proxyConnection, true );
*/
if (!connection_error_signaled) {
ces.fireConnectionErrorOccurred(sqle);
connection_error_signaled = true;
}
}
return sqle;
}