Transacciones y concurrencia

Sistemas de persistencia de
objetos
Transaccin ACID

Es la demarcacin 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 ilusin de que cada usuario es
nico en la base de datos  aslan 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 ms puede
escribir

Oracle y PostgreSQL usan MVCC

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

Problemas debidos a
concurrencia

Actualizacin perdida (lost update)

Lectura sucia (dirty read)

Lectura no repetible (non repetible read)

Doble actualizacin (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 ms especial de unrepeatable txB inserta (o modifica)
rpida y modifica datos read. La actualizacin de nuevos datos que txA va a
que vuelve a necesitar txA txB es sobreecrita por la detectar ms 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 produccin

Si se pone nivel muy restricitivo se
ralentiza mucho el acceso

Si se pone muy bajo aparecern datos
inconsistentes difciles de depurar

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

Cul 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 aaden estos
controles a la aplicacin

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

Ajuste del nivel en Hibernate

Hibernate nativo usa por defecto el nivel de la

conexin JDBC

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

Depende de la BDD, hay que consultar la
documentacin

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
aplicacin

El control optimista adems permite
detectar cambios en actualizaciones
entre trx de sistema
La solucin optimista es
ersin a los
aadir versin
objetos

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

Versionado de objetos con
campo versin

Aadir informacin al objeto para poder
detectar cambios entre el estado
detached y persistent

Campo versin (un entero)

Timestamp (de la ltima modificacin)

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

 Tipos vlidos
para
versionado

Mapeado de campos
!

Sin get/set

JPA gestiona los campos

versin de forma
automtica

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

Qu provoca cambio de
versin?

No estndar JPA

Hibernate:

Cualquier cambio en un campo de la entidad

Cambios en campos de Value Types

Cambios en associaciones @ToMany
(colecciones de entidades)

Aadir o quitar elementos a la coleccin

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

Solo vlido para objetos que se hayan
cargado en la misma sesin

NO es JPA
estndar

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

Control pesimista

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

Pero en algunas ocasiones esta proteccin no se consigue
En este entretiempo otra
trx puede haber
cambiado la descripcin

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

versin

Fuerza cambio de versin

que no se producira

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