Si j'accède à UserTransaction, cela signifie-t-il que j'utilise la validation en 2 phases ou XA?

Question

UserTransaction ut = recherche .... ut.beginTransaction(); saveToFooDB(); statelessEjb.transactionSupportedMethod(); // enregistre quelque chose dans la BD de Foo saveToFooDB(); ut.commit(); Si je faisais ce qui précède, je crois comprendre que ce n'est pas une transaction XA car elle ne couvre pas plusieurs ressources (comme DB plus JMS). Est-ce que ma compréhension est correcte?

Answer 1

source de données peut être configuré de deux types:

• XA: ces datasource peut participer à la distribution des transactions
• Local: aussi appelé non-XA, ils ne peuvent pas participer à une distribution transaction

Le UserTransaction est défini dans la spécification JTA qui décrit comment coordonner le participant dans un dis transaction tributaire.

Le serveur d'application qui implémente la spécification JTA est toutefois libre de faire beaucoup d'optimisations. L'un d'entre eux est le last-agent-optimization, ce qui permet au dernier participant de la transaction distribuée d'être Local. Un commit régulier est ensuite effectué pour les derniers participants. S'il n'y a qu'un seul participant, c'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 le protocole de validation en deux phases full-blow.

Pour voir Glassfish:

• last-agent-optimization
• configure JDBC data source

EDIT

Paragraphe "champ d'opération" de GlassFish documentation explique mieux que moi. Je suppose que c'est la même chose pour tous les serveurs d'applications.

Une transaction locale ne concerne qu'une seule ressource non XA et exige que tous les composants d'application participants exécutent au sein d'un processus. L'optimisation de transaction locale est spécifique au gestionnaire de ressources et est transparente à l'application Java EE .

Dans le serveur d'applications, une ressource JDBC est non-XA si elle répond aux les critères suivants:

• Dans la configuration de pool de connexion JDBC, la classe DataSource ne met pas en œuvre la Interface javax.sql.XADataSource.

• La boîte de support global de la transaction n'est pas cochée, ou le paramètre Type de ressource n'existe pas ou est ensemble à javax.sql.XADataSource.

Une transaction reste locale si les conditions suivantes restent fidèles:

• Une et une seule ressource non-XA est utilisé. Si une ressource supplémentaire autre que XA est utilisée, la transaction est abandonnée.
• Aucune transaction d'importation ou d'exportation n'a lieu.

Les transactions qui impliquent plusieurs ressources ou plusieurs participants processus sont distribués ou globale des transactions. Une transaction globale peut impliquer une ressource non-XA si la dernière optimisation d'agent est activée. Sinon, toutes les ressources doivent être XA. La propriété use-last-agent-optimization est définie sur true par défaut. Pour plus d'informations sur la définition de cette propriété , voir Configuration du service de transaction .

Si une seule ressource XA est utilisé dans une transaction , une phase de validation se produit, sinon la transaction ne coordonnée avec un protocole de validation en deux phases .

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, peu importe que vous vous connectiez à des types de ressources uniques ou multiples, tels que JMS et la base de données.

Espérons que ça aide.

Nitin