Si j'accéder UserTransaction cela signifie que j'utilise 2 phase de validation ou XA?

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?

Answer 1

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:

• dernier agent d'optimisation
• configurer la source de données JDBC

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.

Answer 2

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