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




nov-08

JSE JDBC JTA Declarativas (EJB) Alberto M.F.A. [email protected]

2

Control de transacciones

nov-08

Alberto M.F.A. [email protected]

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. [email protected]

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)





De escritura (exclusivo)





todos podemos leer pero nadie escribir nadie puede leer porque voy a escribir y nadie más puede escribir

Oracle y PostgreSQL usan MVCC

nov-08

Alberto M.F.A. [email protected]

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

nov-08

(phantom read)

Alberto M.F.A. [email protected]

6

Problemas debidos a concurrencia (2)

Lost update: Dos trx sin

Dirty read: TrxA lee datos

bloqueo actualizan los mismos datos. La trxB hace rollback y se pierden los datos de trxA

que luego desaparecen por rollback

nov-08

Alberto M.F.A. [email protected]

7

Problemas debidos a concurrencia (3)

Unrepeatable read:

Second lost update: Caso

Durante txA txB es más especial de unrepeatable read. La actualización de rápida y modifica datos que vuelve a necesitar txA txB es sobreecrita por la de txA.

nov-08

Phantom read: Durante txA txB inserta (o modifica) nuevos datos que txA va a detectar más tarde repitiendo la consulta (u otra que depende de ellos)

Alberto M.F.A. [email protected]

8

Niveles de aislamiento ANSI


Read uncommitted





Read commited





Protege de dirty read  B.E. en UPDATE

Repetible read





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

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

Serializable




nov-08

Protege de phantom, dirty y non repetible read B.L. SELECT en tablas o rangos B.E. UPDATE en tablas o rangos Alberto M.F.A. [email protected]

9

Ajuste del nivel de aislamiento


Se si pone mal problemas:


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








nov-08

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 Alberto M.F.A. [email protected]

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


nov-08

Pero no lo tienen todas las BDD (oracle no lo tiene, PostgreSQL tampoco, …) Alberto M.F.A. [email protected]

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


nov-08

Con tener la BDD en read commited por defecto sirve para el 90% si se añaden estos controles a la aplicación Alberto M.F.A. [email protected]

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. [email protected]

13

Control pesimista y optimista ROLLBACK

Lock

Lock

v1.0

Lock

ROLLBACK PESIMISTA

nov-08

v1.0

v2.0

En BDD ya no es v1.0 OPTIMISTA

Alberto M.F.A. [email protected]

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. [email protected]

15

Versionado de objetos con campo versión


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



nov-08

Campo versión (un entero) Timestamp (de la última modificación)

Alberto M.F.A. [email protected]

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. [email protected]

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)





nov-08

Añadir o quitar elementos a la colección

No provoca cambios modificar entidades asociadas Alberto M.F.A. [email protected]

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. [email protected]

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. [email protected]

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. [email protected]

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. [email protected]

22