Si j'accéder UserTransaction cela signifie que j'utilise 2 phase de validation ou XA?
-
19-09-2019 - |
Question
UserTransaction ut = recherche .... ut.beginTransaction (); saveToFooDB (); statelessEjb.transactionSupportedMethod (); // enregistre quelque chose à la Foo DB saveToFooDB (); ut.commit ();
Si je faisais ce qui précède alors je crois comprendre que ce n'est pas une transaction XA car elle ne couvre pas sur de multiples ressources (comme DB, plus JMS). Est-ce que je comprends bien?
La solution
La source de données peut être configuré de deux types:
- XA : ces datasource peuvent participer à la distribution des transactions
- Local : aussi appelé non-XA, ils ne peuvent pas participer à une transaction distribuée
Le UserTransaction
est défini dans la spécification JTA qui décrivent la façon de coordonner le participant à une transaction distribuée.
Le serveur d'application qui implémente la spécification JTA est cependant libre de faire beaucoup d'optimisations. L'un d'eux est le last-agent-optimization
, ce qui permet au dernier participant à la transaction distribuée à être Local . Une livraison régulière est alors fait pour les derniers participants. S'il n'y a qu'un seul participant alors il est toujours le cas.
En bref:
- si vous avez plus d'un participant, XA et 2 phase de validation doivent être utilisés
- s'il n'y a qu'un seul participant, plus le soutien du serveur d'applications source de données locales et ne pas utiliser toute la phase de soufflage 2 protocole de validation.
Pour voir Glassfish:
EDIT
Le paragraphe "champ de transaction" de GlassFish documentation explique mieux que moi. Je suppose que c'est le même pour tous les serveurs d'application.
Une transaction locale ne concerne qu'un seul ressources non-XA et exige que tous les participation des composants d'application exécuter dans un seul processus. Local l'optimisation des transactions est spécifique au gestionnaire de ressources et est transparent à la Java EE application.
Dans le serveur d'applications, un JDBC ressource est non-XA si elle répond aux les critères suivants:
Dans la configuration du pool de connexion JDBC, la classe DataSource ne met pas en œuvre la Interface javax.sql.XADataSource.
La prise en charge immédiate Global Transaction est pas cochée, ou la ressource paramètre Type n'existe pas ou est mis à javax.sql.XADataSource.
Une transaction reste locale si la conditions suivantes restent valables:
- Une et une seule ressource non-XA est utilisé. En cas de non-XA supplémentaire ressource est utilisée, la transaction est avortée.
- Aucune transaction a eu lieu l'importation ou l'exportation.
Les transactions impliquant plusieurs ressources ou plusieurs participants les processus sont distribués ou mondial transactions. Une transaction globale peut impliquer une ressource non-XA si la dernière l'optimisation de l'agent est activé. Dans le cas contraire, toutes les ressources suffisantes doivent être XA. L'utilisation en dernier agent d'optimisation la propriété est définie sur true par défaut. Pour plus de détails sur la façon de définir cette propriété, voir Configuration du Service de transaction.
Si une seule ressource XA est utilisé dans un transaction, une phase de validation se produit, sinon la transaction est en coordination avec une validation en deux phases protocole.
Autres conseils
Une fois que vous démarrez le UserTransaction, puis obtenir une connexion à la ressource (par exemple, les bases de données) en utilisant une usine de connexion qui est déclarée xa-soutien, cela signifie que la connexion fera partie de la transaction XA. En outre, il n'a pas d'importance du tout si vous vous connectez à un ou plusieurs types de ressources comme JMS et base de données.
L'espoir qui aide.
Nitin