Utilisation de la tentative d'accès WSJPA

Dans l'API JPA (Java™ Persistence API), la tentative d'accès (access intent) spécifie le niveau d'isolement et le niveau de verrouillage utilisés lors de la lecture de données à partir d'une source de données. La tentative d'accès contrôle le niveau d'isolement JDBC et détermine si des verrous de lecture, de mise à jour ou d'accès exclusif sont acquis lors de l'extraction de données.

Pourquoi et quand exécuter cette tâche

Pour un fournisseur de persistance JPA sur le serveur d'applications, l'application peut spécifier l'isolation et le mode ReadLockMode basé sur un Nom d'activité. Le Nom d'activité offre un meilleur contrôle sur l'application de ces caractéristiques. L'application définit un ensemble de types d'entités et leur tentative d'accès correspondante pour chaque nom de tâche (TaskName) défini dans une unité de persistance.
Remarque : La tentative d'accès JPA est une extension WSJPA (JPA for WebSphere) d'OpenJPA.
Restriction :
  • La tentative d'accès est disponible pour l'application dans l'environnement du serveur Java EE
  • La tentative d'accès est applicable aux méthodes d'interface du gestionnaire d'entités de non-requêtes. La requête utilise l'interface de conseils relatifs à la requête pour définir son isolation et lire les valeurs de verrouillage.
  • La tentative d'accès est disponible uniquement pour les bases de données DB2.
  • La tentative d'accès est active uniquement lorsque le gestionnaire de verrou pessimiste est utilisé. Ajoutez la propriété suivante à la liste des propriétés de l'unité de persistance. <property name="openjpa.LockManager" value="pessimistic"/>
Tableau 1. Propriétés et descriptions de tentative d'accès. Le tableau suivant compare le mécanisme de tentative d'accès mis en oeuvre dans les beans entity EJB (Enterprise JavaBeans) 2.x et les propriétés de tentative d'accès JPA :
Tentative d'accès pour les beans entity EJB 2.x dans WebSphere Tentative d'accès JPA Description
optimiste isolation : Read Committed Les données sont lues mais aucun verrou n'est suspendu. L'ID de version est utilisé au moment de la mise à jour pour garantir l'intégrité des données. Les autres transactions peuvent lire et mettre à jour les données.
lockManager : Optimiste
conseil Requête : ReadLockMode : READ
pessimistic read isolation : Repeatable Read Les données sont lues avec des verrous partagés. Les autres transactions tentant de mettre à jour les données sont bloquées.
lockManager : Optimiste
conseil Requête : ReadLockMode : READ
pessimistic update isolation : Repeatable Read Les données sont extraites avec la mise à jour ou le verrou exclusif. Les autres écritures sont bloquées jusqu'à validation. Cette demande d'accès peut être utilisée pour sérialiser le droit de mise à jour aux données lorsqu'il y a plusieurs programmes d'écriture.
lockManager : Pessimiste
conseil Requête : ReadLockMode : WRITE
pessimistic exclusive isolation : Sérialisable Les données sont extraites avec la mise à jour ou le verrou exclusif. Les autres écritures sont bloquées jusqu'à validation. Cette demande d'accès peut être utilisée pour sérialiser le droit de mise à jour aux données lorsqu'il y a plusieurs programmes d'écriture.
lockManager : Pessimiste
conseil Requête : ReadLockMode : WRITE
Un Nom d'activité est défini en fonction du contexte d'une transaction par l'un des éléments suivants :
  • Le nom de tâche (TaskName) est automatiquement défini dans le conteneur d'EJB lorsqu'une transaction commence en utilisant une transaction locale WebSphere (transaction non spécifiée EJB), une transaction globale JTA dans une Transaction gérée par conteneur (CMT) ou une transaction globale initiée par l'utilisateur dans une transaction gérée par bean (BMT)
  • Le Nom d'activité est défini manuellement dans une application à l'aide de l'API TaskNameAccessor fournie pour JPA.

L'utilisation de noms de tâche permet de spécifier la tentative d'accès à l'échelle d'une demande plutôt que dans le fichier persistence.xml, qui a une portée de niveau application et qui s'applique donc à toutes les entités. Une requête est souvent contenue dans une méthode ou un composant utilisé dans de nombreux contextes de transactions différents. Certains de ces contextes peuvent nécessiter une tentative d'accès avec lecture reproductible et verrou de mise à jour, alors que d'autres non.

Le niveau d'isolement et les verrous en lecture peuvent être indiqués sur :
  • Une portée d'application dans le fichier persistence.xml. Ces niveaux d'isolement et types de verrou de lecture sont des propriétés spécifiées dans le fichier persistence.xml. Ils s'appliquent à toutes les entités définies dans l'unité de persistance.
  • Une portée de niveau transaction dans le nom de tâche. Les suggestions (hints) de niveau transaction annulent et remplacent celles du niveau application.
  • Une instance de requête avec un conseil de requête. Le conseil de requête peut être utilisé pour substituer l'isolement et le mode ReadLockMode pour une instance de requête spécifique. Une suggestion dans une requête (query hint) prévaut sur le niveau d'isolement et les verrous de lecture spécifiés dans la portée de niveau application ou transaction.

Procédure

  1. Définition d'un Nom de tâche à l'aide de l'API TaskNameAccessor Cette tâche explique comment utiliser l'API TaskNameAccessor pour définir le nom de tâche (TaskName) JPA à l'exécution.
  2. Spécification d'un nom de tâche dans une unité de persistance JPA Cette tâche explique comment spécifier un nom de tâche (TaskName) dans une unité de persistance JPA.

Que faire ensuite

Pour plus d'informations sur la tentative d'accès, voir la rubrique intitulée Service de tentative d'accès.

Icône indiquant le type de rubrique Rubrique de tâche



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=tejb_accessintentjpa
Nom du fichier : tejb_accessintentjpa.html