Transacciones y concurrencia. Sistemas de persistencia de objetos

Transcripción

1 Transacciones y concurrencia Sistemas de persistencia de objetos

2 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. 2

3 Control de transacciones nov-08 Alberto M.F.A. 3

4 Excepciones JPA Todas NO chequeadas 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. nov-08 Alberto M.F.A. alb@uniovi.es 4

5 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

6 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

7 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 luego desaparecen por rollback nov-08 Alberto M.F.A. alb@uniovi.es 7

8 Problemas debidos a concurrencia (3) Unrepeatable read: Durante txa txb es más rápida y modifica datos que vuelve a necesitar txa Second lost update: Caso especial de unrepeatable read. La actualización de txb es sobreecrita por la de txa. 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) nov-08 Alberto M.F.A. alb@uniovi.es 8

9 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

10 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

11 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

12 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

13 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

14 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

15 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 añadir versión a los objetos nov-08 Alberto M.F.A. alb@uniovi.es 15

16 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

17 Mapeado de campos Tipos válidos para versionado! Sin get/set JPA gestiona los campos versión de forma automática nov-08 Alberto M.F.A. 17

18 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 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

19 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. 19

20 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. 20

21 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

22 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