Exemple : Contrôle de cohérence lecture-lecture
Le contrôle de cohérence lecture-lecture ne s'applique qu'aux beans LifeTimeInCache dont les données sont lues à partir d'une autre transaction.
Scénario d'utilisation
Pour les tentatives d'accès de lecture reproductible(RR), le produit vérifie que les données sont cohérentes avec celles du magasin de données et s'assure qu'aucune mise à jour n'est effectuée après la vérification. Pour les tentatives d'accès de lecture validée(RC), le produit vérifie que les données sont cohérentes au point de vérification mais ne garantit pas qu'elles n'ont pas été modifiées après la vérification. Le bean LifeTimeInCache se comporte alors comme les beans non-LifeTimeInCache beans.
Vous disposez de trois options de définition du contrôle de cohérence, comme illustré dans les scénarios suivants concernant le calcul des intérêts sur le compte bancaire de "Anne". Dans chaque cas, le magasin de données se partage entre cette application de persistance gérée par conteneur (CMP) EJB pour calculer les intérêts et d'autres applications telles que la persistance gérée par bean (BMP) EJB, la connectivité JDBC (Java Database Connectivity) ou des applications existantes. Dans chaque cas également, le compte EJB est configuré comme bean à longue durée de vie.
NONE
- Le serveur est démarré.
- User 1 de Transaction 1 appelle Account.findByPrimaryKey("10001") ; les données du compte de Anne, lues à partir de la base de données, présentent un solde de $100.
- L'enregistrement de Anne est mis en cache par le gestionnaire de persistance sur le serveur.
- User2 écrit un appel JDBC et passe le solde à $120.
- User 3 de Transaction 2 appelle Account.findByPrimaryKey() pour le compte "10001" ; les données du compte de Anne, lues à partir du cache, présentent un solde de $100.
- Les intérêts de Anne sont calculés mais le résultat risque d'être incorrect en raison d'un problème au niveau de l'intégrité des données.
Contrôle lecture-lecture AT_TRAN_BEGIN
- Le serveur est démarré.
- User 1 de Transaction 1 appelle Account.findByPrimaryKey("10001") ; les données du compte de Anne, lues à partir de la base de données, présentent un solde de $100.
- L'enregistrement de Anne est mis en cache par le gestionnaire de persistance sur le serveur.
- User2 écrit un appel JDBC et passe le solde à $120.
- User 3 de Transaction 2 appelle Account.findByPrimaryKey() pour le compte "10001" ; les données du compte de Anne, lues à partir du cache, présentent un solde de $100.
- PM effectue un contrôle lecture-lecture sur le compte de Anne et constate que le solde de 100 a changé. Une requête de base de données est émise pour extraire le solde $120 et les données du compte de Anne qui se trouvent dans le cache sont réactualisées.
- Les intérêts de Anne sont calculés, la transaction effectuée car l'intégrité des données est préservée.
Contrôle lecture-lecture AT_TRAN_END
- Le serveur est démarré.
- User 1 de Transaction 1 appelle Account.findByPrimaryKey("10001") ; les données du compte de Anne, lues à partir de la base de données, présentent un solde de $100.
- L'enregistrement de Anne est mis en cache par le gestionnaire de persistance sur le serveur.
- User2 écrit un appel JDBC et passe le solde à $120.
- User3 de Transaction 2 appelle Account.findByPrimaryKey() pour le compte "10001", les données du compte de Anne, lues à partir de la base de données, présentent un solde de $100.
- Les intérêts de Anne sont calculés.
- En fin de transaction 2, PM effectue un contrôle lecture-lecture sur le compte de Anne et constate que le solde de 100 a changé.
- PM annule la transaction et invalide le cache. La transaction échoue et l'intégrité des données est de nouveau préservée.