Remarques sur la programmation du service DMS (Data Mediator Service) EJB
Lorsque vous commencez à développer vos applications en vue de tirer parti du Data Mediator Service (DMS) Enterprise JavaBeans (EJB) fourni dans le produit, tenez compte des éléments décrits ci-après.
Modèle de programmation EJB
Le service DSM EJB ne prend en
charge qu'un sous-ensemble du modèle de programmation EJB.
- Lorsque vous utilisez des paramètres de collection d'EJB pour extraire des données
d'instances d'EJB ou si vous utilisez applyChanges pour mettre à jour des instances d'EJB
:
- Le service DMS EJB utilise des interfaces locales pour les beans enterprise. Les appels Getter et setter des zones CMP (Container Managed Persistence) doivent être promus sur les interfaces locales, de même que toutes les méthodes EJB employées dans les expressions de requête.
- Pour que le médiateur crée un EJB, une méthode create utilisant la classe de clés
primaires comme seul argument défini dans l'interface home EJB. S'il n'existe aucune méthode de ce type, vous devez fournir un adaptateur capable de
gérer l'opération de création. De plus, l'interface EJBLocalHome définie pour l'EJB doit
inclure (outre la méthode create) la méthode suivante :
findByPrimaryKey(<key class>) remove (java.lang.Object) create (<key class>)
- L'appel de la méthode applyChanges directement dans la base de données entraîne les
opérations suivantes :
- Mise à jour du conteneur ignorée. Vous devez forcer une régénération dès que possible une fois la transaction terminée et en utilisant les options appropriées de mise en cache du conteneur.
- Maintenance des relations CMR des EJB ignorée. Vous devez vous appuyer sur l’indicateur RI de la base de données pour la maintenance des relations qui n'ont pas été extraites dans le datagraphe.
- Les zones CMP doivent être des types autorisés. Pour la liste de ces types, voir Syntaxe de la requête du médiateur d'EJB.
- Les zones CMP définies par l'utilisateur qu'utilisent les convertisseurs/composeurs d'EJB ne sont pas prises en charge.
Le tableau ci-dessous indique les éléments du modèle de programmation d'EJB non pris en charge par le service DMS EJB.
extraction directe à partir de la bd | extraction à partir du conteneur d'EJB | mise à jour directe dans la bd | mise à jour via l'EJB | |
---|---|---|---|---|
héritage de persistance d'EJB | Non | Non | Non | Non |
zone CMP EJB avec convertisseur | Non | Yes | Non | Yes |
Transactionnel
- Tous les appels du médiateur ,y compris create, doivent être effectués dans le cadre d'une transaction (transaction utilisateur ou transaction de conteneur). Les divers appels du médiateur, y compris create, getGraph, et applyChanges, ne doivent pas être effectués au sein de la même transaction. Le plus souvent, les appels sont effectués dans des transactions distinctes.
Tentative d'accès
- Lorsque la requête de médiateur se réfère à un EJB à l'aide de son ASN (Abstract Schema Name), les données sont extraites directement à partir de la base de données. La tentative d'accès et le niveau d'isolement utilisés sur la connexion de source de données correspondent à la tentative d'accès spécifiée dans le profil d'application pour la tentative d'accès de requête dynamique EJB. Il est conseillé de définir une tentative d'accès optimiste pour votre application car un datagraphe doit être utilisé dans un modèle de programmation déconnecté.
- Lorsque le médiateur extrait les données à l'aide d'une collection EJB, la tentative d'accès spécifiée dans le profil d'application est utilisée si l'EJB requiert une activation.
- Lors de l'exécution de applyChanges, le contrôle des accès concurrents permet de vérifier certaines zones dans l'objet de données avant d'appliquer les changements à la base de données. Les mises à jour sont généralement effectuées dans une autre transaction à partir de l'extraction. Par conséquent, pour éviter de perdre des mises à jour, il est nécessaire de vérifier qu'une autre transaction n'a pas mis à jour les données. Lors de la définition de l'EJB en mappage RDB, vous pouvez spécifier une ou plusieurs zones EJB en tant que prédicats optimistes. Les zones permettent d'effectuer la vérification, en comparant la valeur de la base de données actuelle à la valeur antérieure comprise dans le journal des modifications du datagraphe. Si la vérification réussit, la valeur actuelle des zones est écrite dans la base de données. Si la comparaison renvoie la
valeur false et que la mise à jour échoue, une exception se produit. Toute cette procédure s'effectue dans une seule instruction, à laquelle s'ajoutent des prédicats supplémentaires, comme dans l'exemple suivant. La zone optimisticPredicate est myColumn1.
update myTable set myColumn1="nouvelle valeur1", myColumn2="nouvelle valeur2"where myKey="valeur de clé" and myColumn1="ancienne valeur1"
- Une fois applyChanges exécutée via le conteneur d'EJB, les valeurs courantes des beans enterprise sont comparées avec les anciennes valeurs des zones de prédicat optimiste. Si les valeurs sont différentes, une exception se produit.
- Si vous avez défini une ou plusieurs zones EJB en tant que optimisticPredicates, au moins une des zones optmisticPredicate doit être extraite dans l'objet de données pour que le SDO puisse être mis à jour. Sinon, applyChanges renvoie une exception. La zone doit être mise à jour par l'appelant ou par un déclencheur de la base de données ; le médiateur n'incrémente pas et ne définit pas automatiquement la zone.
- Les zones ne sont pas toutes vérifiées ; seules celles marquées comme optimisticPredicate dans le mappage EJB-RDB font l'objet de cette vérification.
- Notez que l'outil de mappage EJB permet de n'utiliser aucune zone optimisticPredicate. Dans ce cas, le médiateur réalisera les mises à jour sans aucune vérification.
- Les opérations de création et de suppression n'utilisent pas les zones de prédicat optimiste.
- Lors de l'application des changements dans les instances EJB, il se peut que l'EJB doive d'abord être activé. Dans ce cas, le système applique la tentative d'accès appropriée qui est associée aux méthodes EJB. Il est conseillé d'exécuter applyChanges dans un profil avec tentative d'accès optimiste ; sinon, la logique d'accès concurrent optimiste est appelée deux fois (une première fois lors de la copie des valeurs d'objet de données dans l'EJB, une seconde fois lorsque le gestionnaire de persistance compare les valeurs antérieures des zones EJB à l'enregistrement de base de données).
- La tentative d'accès utilisée par le médiateur lors de l'extraction directe à partir de la base de données est la tentative d'accès par défaut définie pour l'EJB nommé dans la première instruction de requête.
Meilleures pratiques
- Vous pouvez appeler getGraph sur une instance de médiateur, mettre à jour le graphique de données renvoyé, puis appeler applyChanges sur une autre instance de médiateur. Mais si l'instance de médiateur peut différer, la forme de la requête doit être identique. La forme de la requête fait référence au nombre et à l'ordre des instructions de requête, aux zones et aux relations spécifiées dans les clauses SELECT et FROM, etc.
- Evitez, si possible, les appels répétés à createMediator. Utilisez des requêtes avec paramètres et getGraph pour transmettre différentes valeurs de paramètre.