10
votes

Pourquoi les transactions imbriquées ne sont pas prises en charge en JTA

Pourquoi les transactions imbriquées sont-elles appuyées par JTA? Est-ce en raison de la complexité de les mettre en œuvre (que je doute) ou du principe de conception?


2 commentaires

Il existe un bon article sur les transactions imbriquées, JTA et XA: JBOSSTS.BLOGSPOT .COM / 2009/03 / NISH-transaction-support.html


Je me demande si ce que je faisais vous aidera. Vérifiez ici ici Stackoverflow.com/Questtions/14184703/...


3 Réponses :


3
votes

(comme @piotr Nowicki souligne, JTA fait autorise les transactions imbriquées, mais ceci est facultatif non obligatoire.)

pourquoi? C'est l'une de ces questions impossible à répondre avec aucune certitude, à moins que vous n'ayez l'une des personnes "dans la salle" lorsque les décisions ont été prises.

  • Cela pourrait être la complexité inhérente à inclure des transactions imbriquées dans le cadre de la spécification. Ou complexité apparente à l'époque; C'est-à-dire qu'ils ne savaient pas qu'ils savaient comment faire un bon travail de les spécifier.

  • Il est possible qu'ils pensaient qu'il n'y avait pas assez de demande.

  • Ce pourrait être une pression temporelle ... ou une simple épuisement.

  • Cela pourrait être "raisons commerciales"; par exemple. Certains fournisseurs ne veulent pas interférer avec les horaires de lancement de produits en développant la portée de la spécification.

    Mais, l'essentiel est que si vous voulez que la réponse réelle , vous auriez besoin de demander aux personnes du groupe de travail qui a écrit des spécifications de la JTA. (Et je doute qu'ils vous disent ... sur le record.)


0 commentaires

3
votes

Son ni la réponse est affaire.

De nombreux conteneurs tels que JBoss fournissent des gestionnaires de transactions alternatives plus complexes qui soutiennent des concepts comme des transactions imbriquées, mais d'autres comme Glassfish ne le font pas. Pourtant, les deux sont conformes à Java EE. L'idée est de garder la spécificité simple à réduire la barrière de la conformité des fournisseurs.

Pourquoi forcer quelqu'un à mettre en œuvre un gestionnaire de transactions complexe qui ne couvre que 0,5% des cas d'utilisation transactionnelle ou de la conformité de Java EE?

Rien n'empêche des fournisseurs ambitieux d'aller au-delà de la spécification, mais ils n'ont rien à quitter.


0 commentaires

4
votes

JTA Spécification ne dit pas que le système ne prend pas en charge les transactions imbriquées - celles-ci juste ne nécessitent pas les implémentations pour le soutenir.

Les extraits suivants sont extraits de la spécification JTA 1.1:

p. 11, 13; 3.1 Interface utilisateurTransaction et 3.2 Interface TransactionManager

"La prise en charge des transactions imbriquées est non requise "

p. 13, 3.2.1 Démarrage d'une transaction

" si la mise en œuvre du gestionnaire de transactions ne prend pas en charge les transactions imbriquées , la Transactionmanager.begine méthode jette la noteupportedexception lorsque le Le thread d'appel est déjà associé à une transaction. "

Il pourrait y avoir un problème avec le Xaresource que vous pourriez essayer d'enrôler avec la transaction en cours (je pense que cela pourrait être lié à la spécification X / Open XA):

3.4.4 Association des transactions

xaresource ne prend pas en charge les transactions imbriquées . C'est une erreur pour le Xaresource.start méthode à appeler sur une connexion actuellement associée avec une transaction différente.