Poniendo tiempos de espera en las declaraciones preparadas

Question

Estoy tratando de usar declaraciones preparadas que operan en una base de datos ubicada bastante lejos, hay un retraso considerable y falta de fiabilidad en la conexión de red utilizada para acceder a esta base de datos. Los tiempos de inactividad de hasta un minuto son comunes. El problema es que en el caso de una falla de este tipo, si mi programa intenta ejecutar cualquier declaración preparada, todo el hilo entra en espera infinita. Nunca se agota y simplemente permanece bloqueado, esperando una respuesta de la base de datos.

Intenté utilizar el método setQueryTimeout() para poner explícitamente un tiempo de espera en la ejecución, pero parece que hay algún problema con este método en el que no puede funcionar correctamente si falla la red.

¿Hay alguna forma alternativa de evitar esto?

Answer 1

En mi conocimiento, no hay tal alternativa si la red falla.

Los detalles exactos de setQueryTimeout implican que el controlador JDBC recibe instrucciones de enviar una señal Fuera de banda (al menos en el caso del controlador Oracle JDBC) a la base de datos para detener la ejecución de la Declaración preparada; esta parte es importante, ya que depende del soporte integrado en el controlador y la base de datos. Después de esto, depende de la base de datos programar la ejecución de esta operación 'cancelar'; esto podría tomar un tiempo si las cosas tienen que ser revertidas o si otras transacciones tienen que ser ejecutadas, etc.

Dada la primera parte de la naturaleza de la implementación, es bastante improbable que una implementación "limpia" de un tiempo de espera característica puede ser establecida. Es posible que desee investigar el uso de un administrador de transacciones aquí (quizás JTA), pero no estoy seguro si encontrará otro conjunto de excepciones extrañas (piense en excepciones heurísticas).

Adición

El uso de un controlador de hilo que supervisa la ejecución de otros hilos y mata a los hilos 'pegado' podría ser una mala idea. This SO question ayudaría a responder por qué se debe evitar tal actividad. Este es también el tactic chosen by WebLogic Server.