Incluso si usa el conjunto de conexiones JDBC, ya sea el servidor de aplicaciones provisto o el pool común de Apache, vale la pena codificar una lógica de reintento. En función de la configuración de su servidor de aplicaciones, el servidor de la aplicación purgaría todas las conexiones agrupadas y recrearía un nuevo conjunto de conexiones. Aquí hay una muestra:
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
//
// How many times do you want to retry the transaction
// (or at least _getting_ a connection)?
//
int retryCount = 5;
boolean transactionCompleted = false;
do {
try {
conn = getConnection(); // assume getting this from a
// javax.sql.DataSource, or the
// java.sql.DriverManager
retryCount = 0;
stmt = conn.createStatement();
String query = "Some sample SQL";
rs = stmt.executeQuery(query);
while (rs.next()) {
}
rs.close();
rs = null;
stmt.close();
stmt = null;
conn.close();
conn = null;
transactionCompleted = true;
} catch (SQLException sqlEx) {
//
// The two SQL states that are 'retry-able'
// for a communications error.
//
// Only retry if the error was due to a stale connection,
// communications problem
//
String sqlState = sqlEx.getSQLState();
if ("Substitute with Your DB documented sqlstate number for stale connection".equals(sqlState)) {
retryCount--;
} else {
retryCount = 0;
}
} finally {
if (rs != null) {
try {
rs.close();
} catch (SQLException sqlEx) {
// log this
}
}
if (stmt != null) {
try {
stmt.close();
} catch (SQLException sqlEx) {
// log this
}
}
if (conn != null) {
try {
//
// If we got here, and conn is not null, the
// transaction should be rolled back, as not
// all work has been done
try {
conn.rollback();
} finally {
conn.close();
}
} catch (SQLException sqlEx) {
//
// If we got an exception here, something
// pretty serious is going on, so we better
// pass it up the stack, rather than just
// logging it. . .
throw sqlEx;
}
}
}
} while (!transactionCompleted && (retryCount > 0));
}
El OP usa ** Firebird **, ¿por qué usaría el controlador de Oracle? Entonces, no implementaría la lógica de validación de conexión en mi código, prefiero usar un grupo que implemente esta verificación (y no es necesario usar un controlador JDBC 4.0 para esto). –
Asumiendo que Firebird (de lo cual admito que sé cero) tiene un controlador JDBC, entonces todavía puede usar estas clases. Tenga en cuenta que se les llama UNIVERSAL Connection Pool: es la versión de Oracle de C3P0 o Proxool. Funcionan con cualquier controlador JDBC. Y sí, este conjunto hará la lógica de validación por sí mismo. – Gandalf
Estoy de acuerdo con el conjunto de conexiones "universales". Sin embargo, "cumple con JBDC 4.0" se refiere a un controlador JDBC (Oracle específico esta vez), no un grupo. Ese era mi punto. –