2009-10-07 6 views

Respuesta

55

Si el controlador JDBC cumple con las especificaciones, técnicamente sí, el objeto es seguro para subprocesos, pero debe evitar compartir conexiones entre subprocesos, ya que la actividad en la conexión significará que solo un subproceso será capaz de hacer cualquier cosa a la vez

Debe usar un grupo de conexiones (como Apache Commons DBCP) para asegurarse de que cada subproceso tenga su propia conexión.

+4

Por ejemplo, la aplicación de Postgres no sincronizar el acceso a la bandera autoCommit así que no es seguro para subprocesos. –

+1

Una voz en la parte posterior de mi cabeza me dice que la especificación JDBC requiere que todos los objetos java.sql sean seguros para subprocesos, pero no puedo encontrar una referencia a eso. – skaffman

+11

Su voz puede referirse a http://java.sun.com/j2se/1.3/docs/guide/jdbc/spec/jdbc-spec.frame9.html donde dice "Requerimos que todas las operaciones en todos los java.sql los objetos son seguros para múltiples hilos y son capaces de manejar correctamente el hecho de tener varios hilos llamando simultáneamente al mismo objeto ". – janko

9

java.sql.Connection es una interfaz. Por lo tanto, todo depende de la implementación del controlador, pero en general debe evitar compartir la misma conexión entre diferentes subprocesos y usar grupos de conexiones. También se aconseja tener un número de conexiones en el grupo superior al número de subprocesos de trabajo.

+7

Una interfaz es un contrato, y un contrato * podría * especificar que todas las implementaciones deben ser seguras para subprocesos. Es solo que este no es el caso para java.sql.Connection. –

+1

Sí, la interfaz es un contrato y puede poner algunos requisitos adicionales en la documentación que describe el contrato, pero como dijo la documentación de java.sql.Connection no define el requisito de seguridad de subprocesos, e incluso si lo definió, aún la seguridad no es algo que pueda describirse y hacerse cumplir estrictamente. La implementación aún puede violar el contrato (a veces por error, a veces por diseño, por ejemplo IdentityHashMap). –

+0

@AndreyAdamovich: "se recomienda tener un número de conexiones en el grupo superior al número de subprocesos de trabajo" ¿por qué? Quiero decir, si tengo muchas conexiones en el grupo de conexiones, terminaré con el problema de Thrashing. –

0

Teníamos ArrayOutOfBoundsException en el caché de sentencias de Websphere de su fuente de datos agrupados, y tuvimos que deshabilitar ese caché.

Tuvimos un tratamiento que se estaba bloqueando.

Todo eso debido al acceso actual a la conexión, por lo que la conclusión por la práctica de la vida real, es que no debes hacer eso.

1

Esto es más bien un viejo hilo, pero para aquellos que están buscando una respuesta con respecto a Microsoft SQL Server, aquí está la respuesta:

SQLServerConnection no es hilo de seguridad, sin embargo varias instrucciones creadas a partir de una única conexión puede procesarse simultáneamente en hilos concurrentes.

y

SQLServerConnection implementa una conexión JDBC de SQL Server.

De todas las formas anteriores, puede compartir declaraciones pero no Conexiones, y en caso de que necesite una conexión en cada hilo, puede usar un grupo de hilos.

Leer más here

Cuestiones relacionadas