Conseils pour l'identification et la résolution des problèmes liés aux tentatives d'accès

Voici les réponses aux questions fréquentes concernant les tentatives d'accès.

La base de données Oracle échoue si aucune règle d'accès n'est appliquée

Aucune règle relative à la tentative d'accès n'a été appliquée et l'application s'exécute avec une base de données DB2 mais échoue avec une base de données Oracle et le message suivant s'affiche : com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: PMGR1001E: No such DataAccessSpec :FindAllCustomers. Le magasin de données d'arrière-plan ne prend pas en charge l'instruction SQL nécessaire à la tentative d'accès : (pessimistic update-weakestLockAtLoad)(collections: transaction/25) (resource manager prefetch: 0) (AccessIntentImpl@d23690a).

Si vous n'avez configuré aucune tentative d'accès, l'accès à toutes les données est soumis à la règle de tentative d'accès par défaut (wsPessimisticUpdate-WeakestLockAtLoad). Sur DB2, le verrou le plus faible est share. Sur les bases de données Oracle, cependant, le verrou le plus faible est update, ce qui signifie que la requête SQL doit contenir une clause FOR UPDATE. Pour y remédier, essayez d'appliquer une règle de tentative d'accès prenant en charge les accès concurrents optimistes.

Appeler une méthode de localisation affiche InconsistentAccessIntentException lors de la phase d'exécution

Cela peut se produire lorsque vous utilisez des règles de tentative d'accès pour appliquer davantage de contrôle sur la manière dont un bean est chargé. Cette exception indique que le bean entity a déjà été chargé dans la même transaction. Cela peut se produire si vous avez appelé une méthode multifinder qui a renvoyé l'instance du bean à laquelle une règle de tentative d'accès X est appliquée ; vous tentez à présent de charger à nouveau le deuxième bean en appelant la méthode findByPrimaryKey à laquelle la tentative d'accès Y est appliquée. La règle de tentative d'accès qui s'applique pour ces deux méthodes est identique.

De la même manière, si l'entité a déjà été chargée une fois dans la transaction à l'aide d'une règle de tentative d'accès configurée dans une méthode finder, il se peut que vous ayez appelé une méthode d'accesseur CMR (Container-Managed Relationship) ayant renvoyé le bean entity configuré pour être chargé à l'aide de la tentative d'accès par défaut de ce bean.

Pour éviter cet incident, assurez-vous que le code ne charge pas deux fois la même instance de bean dans la même transaction à laquelle des règles de tentatives d'accès différentes ont été attribuées. Evitez l'utilisation d'une tentative d'accès au niveau méthode sauf si cela est vraiment nécessaire.

InconsistentAccessIntentException s'affiche dans une relation gérée par conteneur avec deux beans

Une relation gérée par conteneur comporte deux beans. La méthode findByPrimaryKey est appelée sur le premier bean, puis la méthode getBean2, puis une méthode d'accès CMR est appelée sur l'instance renvoyée et InconsistentAccessIntentException s'affiche.

Vous utilisez probablement la fonction de lecture anticipée. Lors du chargement du premier bean, le deuxième bean, soumis à la règle de tentative d'accès appliquée à la méthode finder du premier bean, a lui aussi été chargé. Cependant, vous avez configuré votre méthode d'accesseur CMR du premier bean au second à l'aide d'une règle de tentative d'accès différente. Les méthodes d'accès CMR sont en réalité des méthodes finder ; l'environnement d'exécution se comporte comme si vous tentiez de modifier la tentative d'accès pour une instance ayant déjà été lue dans le magasin de données persistantes.

Pour éviter cela, les beans configurés dans une lecture anticipée sont tous pilotés de sorte à être chargés avec la même règle de tentative d'accès que pour le bean auquel la lecture anticipée est appliquée.

Un bean ayant une relation un à plusieurs avec un deuxième bean affiche une erreur

Un bean ayant une relation un à plusieurs avec un deuxième bean affiche une erreur UpdateCannotProceedWithIntegrityException lorsqu'une instance du deuxième bean est ajoutée à la collection du premier bean

Un bean ayant une relation un à plusieurs avec un deuxième bean affiche une erreur UpdateCannotProceedWithIntegrityException lorsqu'une instance du deuxième bean est ajoutée à la collection du premier bean. Une règle de tentative d'accès en mise à jour pessimiste est appliquée au premier bean.

Une règle de tentative d'accès en lecture a sans doute été appliquée au deuxième bean. Lorsque vous ajoutez le deuxième bean à la collection du premier bean, vous ne mettez pas à jour l'état du premier bean mais modifiez implicitement l'état du deuxième bean. Le deuxième bean contient une clé externe d'accès au premier bean, laquelle est modifiée.

Pour éviter cet incident, assurez-vous qu'une règle de tentative d'accès en mise à jour a été appliquée aux deux éléments de la relation si vous prévoyez de modifier cette dernière lors de l'exécution.


Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rejb_axifaq
Nom du fichier : rejb_axifaq.html