Transacciones

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 dejanel 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 aislamientotradicionalmente 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
bloqueo actualizan los mismos datos. La trxB hace rollback y se pierden los datos de trxA

Dirty read: TrxA lee datos
que luegodesaparecen por rollback

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
txB inserta (o modifica) nuevos datos que txA va a detectar más tarde repitiendo la consulta (u otra que depende de ellos)
8

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

nov-08

Alberto M.F.A. alb@uniovi.es

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 B.L. en

Repetible read
Protege de dirty y non repetible read SELECT, B.E. enUPDATE

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 muybajo 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
Contener 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...