Transacciones y concurrencia

Sistemas de persistencia de
objetos
Transacción ACID

Es la demarcación de una unidad de
trabajo

JPA permite trabajar con varios API de
transacciones

JSE JDBC

JTA

Declarativas (EJB)

nov-08 Alberto M.F.A. alb@uniovi.es 2

Control de transacciones

nov-08 Alberto M.F.A. alb@uniovi.es 3

 Excepciones JPA
Todas las excepciones JPA son
fatales y dejan el contexto de
persistencia inutilizado

Todas las excepciones lanzadas por

EntityManager provocan rollback()

Todas las de Query tb, excepto

NoResultException y
NonUniqueResultException.

Todas NO chequeadas

nov-08 Alberto M.F.A. alb@uniovi.es 4

Control de concurrencia

Las trx ACID crean la ilusión de que cada usuario es
único en la base de datos  aíslan a unos de otros

El aislamiento tradicionalmente se consigue con
bloqueos a nivel de fila, de rangos o de tabla:

De lectura (compartido)

todos podemos leer pero nadie escribir

De escritura (exclusivo)

nadie puede leer porque voy a escribir y nadie más puede
escribir

Oracle y PostgreSQL usan MVCC

nov-08 Alberto M.F.A. alb@uniovi.es 5

Problemas debidos a
concurrencia

Actualización perdida (lost update)

Lectura sucia (dirty read)

Lectura no repetible (non repetible read)

Doble actualización (second lost update)

Lectura fantasma (phantom read)

nov-08 Alberto M.F.A. alb@uniovi.es 6

 Problemas debidos a
concurrencia (2)

Lost update: Dos trx sin Dirty read: TrxA lee datos
bloqueo actualizan los que luego desaparecen por
mismos datos. La trxB rollback
hace rollback y se pierden
los datos de trxA

nov-08 Alberto M.F.A. alb@uniovi.es 7

 Problemas debidos a
concurrencia (3)

Unrepeatable read: Second lost update: Caso Phantom read: Durante txA
Durante txA txB es más especial de unrepeatable txB inserta (o modifica)
rápida y modifica datos read. La actualización de nuevos datos que txA va a
que vuelve a necesitar txA txB es sobreecrita por la detectar más tarde
de txA. repitiendo la consulta (u
otra que depende de ellos)

nov-08 Alberto M.F.A. alb@uniovi.es 8

Niveles de aislamiento ANSI

Read uncommitted

Tiene todos los problemas, solo protege frente a
sobreescrituras (lost update)  B.L. en UPDATE

Read commited

Protege de dirty read  B.E. en UPDATE

Repetible read

Protege de dirty y non repetible read  B.L. en
SELECT, B.E. en UPDATE

Serializable

Protege de phantom, dirty y non repetible read

B.L. SELECT en tablas o rangos

B.E. UPDATE en tablas o rangos
nov-08 Alberto M.F.A. alb@uniovi.es 9
Ajuste del nivel de aislamiento

Se si pone mal problemas:

Solo se van a notar cuando el sistema está
en carga

Cuando ya estamos en producción

Si se pone nivel muy restricitivo se
ralentiza mucho el acceso

Si se pone muy bajo aparecerán datos
inconsistentes difíciles de depurar

nov-08 Alberto M.F.A. alb@uniovi.es 10

¿Cuál escoger?

Depende de necesidades, pero:

Read uncommitted nunca (solo expertos)

Serializable no es frecuente

¿Realmente me van a afectar los phantom reads? 
pocas trx son así

La duda mayor está entre read committed y
repeatable read

Read commited no protege del second lost update y sí
puede ser importante

Repetible read sí protege frente a second lost update

Pero no lo tienen todas las BDD (oracle no lo tiene,
PostgreSQL tampoco, …)

nov-08 Alberto M.F.A. alb@uniovi.es 11

Read commited puede servir…

Casi todas las BDD tienen read committed
por defecto

Con bloqueos pesimistas se consigue
repetible read

Con control optimista se puede evitar el
second lost update

Con tener la BDD en read commited por
defecto sirve para el 90% si se añaden estos
controles a la aplicación

nov-08 Alberto M.F.A. alb@uniovi.es 12

Ajuste del nivel en Hibernate

Hibernate nativo usa por defecto el nivel de la

conexión JDBC

JDBC a su vez usa el nivel por defecto en la BDD

Depende de la BDD, hay que consultar la
documentación

suele ser read commited o repetible read

Con el ajuste se cambia para ¡todas las
transacciones !

Ajuste en persistence.xml
nov-08 Alberto M.F.A. alb@uniovi.es 13
 Control pesimista y optimista

ROLLBACK

Lock Lock Lock v1.0 v2.0 v1.0

ROLLBACK En BDD ya no es v1.0

PESIMISTA OPTIMISTA

nov-08 Alberto M.F.A. alb@uniovi.es 14

Control optimista

Diferencia entre trx de sistema y trx de
aplicación

El control optimista además permite
detectar cambios en actualizaciones
entre trx de sistema
La solución optimista es
ersión a los
añadir versión
objetos

nov-08 Alberto M.F.A. alb@uniovi.es 15

Versionado de objetos con
campo versión

Añadir información al objeto para poder
detectar cambios entre el estado
detached y persistent

Campo versión (un entero)

Timestamp (de la última modificación)

nov-08 Alberto M.F.A. alb@uniovi.es 16

 Tipos válidos
para
versionado

Mapeado de campos
!

Sin get/set

JPA gestiona los campos

versión de forma
automática

nov-08 Alberto M.F.A. alb@uniovi.es 17

¿Qué provoca cambio de
versión?

No estándar JPA

Hibernate:

Cualquier cambio en un campo de la entidad

Cambios en campos de Value Types

Cambios en associaciones @…ToMany
(colecciones de entidades)

Añadir o quitar elementos a la colección

No provoca cambios modificar entidades
asociadas
nov-08 Alberto M.F.A. alb@uniovi.es 18
 Versionado sin campo versión

Solo válido para objetos que se hayan
cargado en la misma sesión

NO es JPA
estándar

nov-08 Alberto M.F.A. alb@uniovi.es 19

Control pesimista

En circunstancias normales el contexto de persistencia da
protección repetible read al haber una única copia en
memoria (aunque la BDD no esté en ese nivel)

Pero en algunas ocasiones esta protección no se consigue
En este entretiempo otra
trx puede haber
cambiado la descripción

Se proyectan
escalares, no
objetos: no hay
chaché de
contexto
nov-08 Alberto M.F.A. alb@uniovi.es 20
 Se impone un
bloqueo en la fila

Control pesimista

El control pesimista sube el nivel a
repetible read sin cambiar BDD

Impone un
bloqueo de fila

nov-08 Alberto M.F.A. alb@uniovi.es 21

Modos de bloqueo

LockModeType.READ

Impone bloqueo de lectura

SELECT * FROM … FOR UPDATE de Oracle (o equivalente)

LockModeType.WRITE

Lo mismo que el anterior pero fuerza el incremento de

versión

Fuerza cambio de versión

que no se produciría

nov-08 Alberto M.F.A. alb@uniovi.es 22