Ejemplo: comprobación de coherencia de lectura a lectura
La comprobación de coherencia de lectura sólo es aplicable a los beans LifeTimeInCache cuyos datos se leen de otra transacción.
Ejemplo de uso
Para los intentos de acceso que son para lectura repetible (RR), esto significa que el producto comprueba que los datos sean coherentes con los del almacén de datos y se asegura de que nadie los actualice después de la comprobación. Para los intentos de acceso que son para lectura comprometida (RC), esto significa que los datos son coherentes en el momento de la comprobación, pero no garantiza que los datos no cambien después de la comprobación. Esto hace que el funcionamiento del bean LifeTimeInCache sea igual que el de los beans non-LifeTimeInCache.
Tiene tres opciones para establecer la comprobación de coherencia, como se muestra en los casos siguientes sobre el cálculo del interés de la cuenta bancaria de "Ana". En cada caso, el almacén de datos lo comparten la aplicación CMP (persistencia gestionada por contenedor) de EJB (Enterprise JavaBeans) para calcular el interés y otras aplicaciones, como BMP (persistencia gestionada por bean) de EJB, JDBC (Java Database Connectivity) o aplicaciones heredadas. Además, en cada caso, la cuenta de EJB se configura como un bean de larga duración.
NINGUNO
- Se inicia el servidor.
- El usuario 1 de la transacción 1 llama a Account.findByPrimaryKey("10001"), los datos de la cuenta de Ana se leen de la base de datos, con un saldo de 100 euros.
- El registro de Ana se coloca en memoria caché mediante el gestor de persistencia (PM - Persistence Manager) en el servidor.
- El usuario 2 escribe una llamada JDBC y cambia el saldo a 120 euros.
- El usuario 3 de la transacción 2 llama a Account.findByPrimaryKey() para la cuenta "10001", los datos de Ana se leen de memoria caché, con un saldo de 100 euros.
- Se calcula el interés de Ana, pero el resultado quizá no sea correcto debido a un problema de integridad de los datos.
Comprobación de lectura a lectura AT_TRAN_BEGIN
- Se inicia el servidor.
- El usuario 1 de la transacción 1 llama a Account.findByPrimaryKey("10001"), los datos de la cuenta de Ana se leen de la base de datos, con un saldo de 100 euros.
- El registro de Ana se coloca en memoria caché mediante el gestor de persistencia (PM - Persistence Manager) en el servidor.
- El usuario 2 escribe una llamada JDBC y cambia el saldo a 120 euros.
- El usuario 3 de la transacción 2 llama a Account.findByPrimaryKey() para la cuenta "10001", los datos de Ana se leen de memoria caché, con un saldo de 100 euros.
- PM realiza una comprobación de lectura a lectura en la cuenta de Ana y se encuentra con que el saldo de 100 ha cambiado. Emite una consulta a la base de datos para recuperar el saldo de 120 euros y los datos de Ana de la memoria caché se renuevan.
- Se calcula el interés de Ana, se continúa con la transacción porque la integridad de los datos está protegida.
Comprobación de lectura a lectura AT_TRAN_END
- Se inicia el servidor.
- El usuario 1 de la transacción 1 llama a Account.findByPrimaryKey("10001"), los datos de la cuenta de Ana se leen de la base de datos, con un saldo de 100 euros.
- El registro de Ana se coloca en memoria caché mediante el gestor de persistencia (PM - Persistence Manager) en el servidor.
- El usuario 2 escribe una llamada JDBC y cambia el saldo a 120 euros.
- El usuario 3 de la transacción 2 llama a Account.findByPrimaryKey() para la cuenta "10001", los datos de Ana se leen de la base de datos, con un saldo de 100 euros.
- Se calcula el interés de Ana.
- Durante el final de la transacción 2, PM realiza una comprobación de lectura a lectura en la cuenta de Ana y se encuentra con que el saldo de 100 ha cambiado.
- PM retrotrae la transacción e invalida la memoria caché. No se puede realizar la transacción y de nuevo la integridad de los datos está protegida.