Dans Weblogic l'inscription dans une transaction distribuée est réalisée par la "connection factory", c'est une case à cocher dans la console (pour JDBC il faut aussi s'assurer que l'on utilise un pilote compatible).
Pour les performances il y a forcément un coût, tu ne peux pas établir un consensus dans un environnement distribué de manière simple mais avec des "file stores" sur des disques dédiés ça marche très bien et avant de se dire que l'on va réinventer la roue il suffit de connaître la complexité des problématiques de consensus (flp ,paxos..) pour laisser faire les gens qui maîtrisent le sujet surtout dans des environnements JEE rodés qui offrent cette possibilité.
Coté fiabilité ça fait plusieurs années qu'on fait du commit à 2 phases sur plusieurs millions de transactions par jour (avec en moyenne 3 ressources participantes) et on a eu un seul cas d'heuristique suite à une erreur d'exploitation.
[^] # Re: Questions
Posté par michael (mickey) . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
Dans Weblogic l'inscription dans une transaction distribuée est réalisée par la "connection factory", c'est une case à cocher dans la console (pour JDBC il faut aussi s'assurer que l'on utilise un pilote compatible).
Pour les performances il y a forcément un coût, tu ne peux pas établir un consensus dans un environnement distribué de manière simple mais avec des "file stores" sur des disques dédiés ça marche très bien et avant de se dire que l'on va réinventer la roue il suffit de connaître la complexité des problématiques de consensus (flp ,paxos..) pour laisser faire les gens qui maîtrisent le sujet surtout dans des environnements JEE rodés qui offrent cette possibilité.
Coté fiabilité ça fait plusieurs années qu'on fait du commit à 2 phases sur plusieurs millions de transactions par jour (avec en moyenne 3 ressources participantes) et on a eu un seul cas d'heuristique suite à une erreur d'exploitation.