OptimisticLockException puede producirse si el nivel de aplicación srv El aislamiento se establece en READ COMMITTED?
-
28-09-2019 - |
Pregunta
Estoy utilizando el servidor de aplicaciones Websphere 7.0.0.0.9 con; OpenJPA 1.2.3-SNAPSHOT'. Tengo la propiedad Conjunto de fuente de datos JDBC webSphereDefaultIsolationLevel = 2 (lectura confirmada). Tengo esta pregunta porque Mi entendimiento es la OptimasticLockException se produce si hay carrera a cometer la misma fila por múltiples hilos. Pero creo que esta situación no debería ocurrir si el servidor de aplicaciones nivel de aislamiento se establece en Lectura confirmada.
Esta es una excepción que estoy recibiendo ..
<openjpa-1.2.3-SNAPSHOT-r422266:907835 fatal store error> org.apache.openjpa.persistence.OptimisticLockException: An optimistic lock violation was detected when flushing object instance
Solución
Tengo esta pregunta porque mi entendimiento es la
OptimisticLockException
se produce si hay carrera a cometer la misma fila por múltiples hilos.
Sí, un OptimisticLockException
será lanzada si el atributo Version
de una entidad es más alto (es decir, ha sido modificado por otra transacción) a comprometer tiempo que cuando se leyó. Esto es ilustrado por la figura siguiente (tomado de JPA 2.0 concurrencia y de bloqueo ):
Sin embargo, creo que esta situación no debería ocurrir si el servidor de aplicaciones nivel de aislamiento se establece en Lectura confirmada.
¿Por qué? Cuando se utiliza un rel="nofollow href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#READ_COMMITTED" LEA nivel de aislamiento comprometido, lee no repetible puede ocurrir pero:
- Esto no afectará en la representación de memoria de datos (
e1
en el ejemplo anterior) - La mayor parte del tiempo, no lo hace volver a leer los datos
- E incluso si lo hace (y realizar una lectura no repetible), una entidad puede todavía conseguir modificado por otro hilo antes de confirmar los cambios.
Para resumir, lectura confirmada no impedirá OptimisticLockException
.