Bravo, vous avez très bien appris le discours commercial de sun ;o)
Pour vous répondre, je ne connais personne qui se soit risqué à faire de la transaction multi-sgbd de cette manière, parce que justement l'atomicité n'est pas garantie.
Si sur un SGBDR je fais un :
BEGIN TRANSACTION
UPDATE TOTO...
UPDATE TATA...
COMMIT
Je suis certain que si le microprocesseur crame brusquement entre les deux updates, lorsque le SGBDR sera redémarré l'update sur la table TOTO sera annulé.
Par contre, si je fais depuis une machine tierce A un :
BEGIN TRANSACTION
UPDATE MachineB.ORACLE.TOTO...
UPDATE MachineC.DB2.TATA...
COMMIT
La machine tierce A est bien obligée d'envoyer un COMMIT successivement à B et à C. Faudrait pas que le microprocesseur grille entre les deux commit, sinon bonjour le bazar ;-)
Une solution possible, serait de gérer également un transaction-log au niveau de la machine tierce A, mais dans ce cas là, si la machine A est down, vous ne devez plus utiliser les SGBDR des machines B et C au risque d'un joyeux bazar... Et puis, une des caractéristiques de JAVA est d'etre complètement isolé du système. Alors comment s'assurer qu'une écriture est effectivement effectuée physiquement et ne traine pas dans un buffer de l'O/S ?
J'ajoute également que les différents SGBDR ont leur propre gestion de concurrence d'accès (certains mettent un verrou exclusif lors d'une eécriture et d'autres non), alors on fait comment si les bases de données sont utilisées par d'autres applis ?
Le mécanisme de répliquation entre 2 SGBDR du même éditeur, et de même version est déjà extrêmement délicat à mettre en oeuvre par l'éditeur du SGBDR lui-même alors ...
Quant à l'histoire de la portabilité qui serait un avantage par rapport à des procédures stockées, ça se réfute. C'est vrai qu'une proc stockée n'est pas portable d'un SGBDR à un autre, mais c'est aussi vrai qu'une requête toute bête en SQL n'est pas portable (quid des IsNull() COALESCE() et autres DECODE() ?).
L'argument des performances se réfute également. On entend dire que les EJB "soulagent" les SGBDR. Il n'en est rien ... ou presque. Les EJB font ce qu'ils veulent, au final c'est bien le SGBDR qui doit gérer les lectures/ecritures de données. L'application serveur peut éventuellement soulager le SGBDR des calculs (on calcule 1+2 au niveau de l'AppServ au lieu du SGBDR) mais :
- Bien souvent, cela supprime la logique ensembliste, ce pour quoi sont justement optimisés les SGBDR.
- L'overhead absolument est énorme, surtout en JAVA avec sa machine virtuelmle, sa sandbox etc. Si vous utilisez la (les) machines qui servent à fournir la puissance de calcul nécessaire à vos EJB pour faire tourner une autre instance de votre SGBDR, avec une réplication entre chaque instance du SGBDR, et un load balancer tout simple, vous vous en sortirez bcp mieux et bcp plus simplement.
EJB c'est un bon modèle, mais c'est pas une panacée. C'est *PARFOIS* utile, tout comme un moniteur transactionnel est *PARFOIS* utile.
Il faut toujours garder une chose en tête, pour savoir douter :
- L'intérêt de SUN est de rendre les clients dépendants d'eux (alors qu'avant ils ne l'étaient pas).
- L'intérêt de SUN est de vendre des machines.
[^] # Re: Houuuuuuuuuuuuuuu
Posté par peau chat . En réponse à la dépêche Apache/PHP et IIS/ASP : pas si bons ?. Évalué à 3.
Pour vous répondre, je ne connais personne qui se soit risqué à faire de la transaction multi-sgbd de cette manière, parce que justement l'atomicité n'est pas garantie.
Si sur un SGBDR je fais un :
BEGIN TRANSACTION
UPDATE TOTO...
UPDATE TATA...
COMMIT
Je suis certain que si le microprocesseur crame brusquement entre les deux updates, lorsque le SGBDR sera redémarré l'update sur la table TOTO sera annulé.
Par contre, si je fais depuis une machine tierce A un :
BEGIN TRANSACTION
UPDATE MachineB.ORACLE.TOTO...
UPDATE MachineC.DB2.TATA...
COMMIT
La machine tierce A est bien obligée d'envoyer un COMMIT successivement à B et à C. Faudrait pas que le microprocesseur grille entre les deux commit, sinon bonjour le bazar ;-)
Une solution possible, serait de gérer également un transaction-log au niveau de la machine tierce A, mais dans ce cas là, si la machine A est down, vous ne devez plus utiliser les SGBDR des machines B et C au risque d'un joyeux bazar... Et puis, une des caractéristiques de JAVA est d'etre complètement isolé du système. Alors comment s'assurer qu'une écriture est effectivement effectuée physiquement et ne traine pas dans un buffer de l'O/S ?
J'ajoute également que les différents SGBDR ont leur propre gestion de concurrence d'accès (certains mettent un verrou exclusif lors d'une eécriture et d'autres non), alors on fait comment si les bases de données sont utilisées par d'autres applis ?
Le mécanisme de répliquation entre 2 SGBDR du même éditeur, et de même version est déjà extrêmement délicat à mettre en oeuvre par l'éditeur du SGBDR lui-même alors ...
Quant à l'histoire de la portabilité qui serait un avantage par rapport à des procédures stockées, ça se réfute. C'est vrai qu'une proc stockée n'est pas portable d'un SGBDR à un autre, mais c'est aussi vrai qu'une requête toute bête en SQL n'est pas portable (quid des IsNull() COALESCE() et autres DECODE() ?).
L'argument des performances se réfute également. On entend dire que les EJB "soulagent" les SGBDR. Il n'en est rien ... ou presque. Les EJB font ce qu'ils veulent, au final c'est bien le SGBDR qui doit gérer les lectures/ecritures de données. L'application serveur peut éventuellement soulager le SGBDR des calculs (on calcule 1+2 au niveau de l'AppServ au lieu du SGBDR) mais :
- Bien souvent, cela supprime la logique ensembliste, ce pour quoi sont justement optimisés les SGBDR.
- L'overhead absolument est énorme, surtout en JAVA avec sa machine virtuelmle, sa sandbox etc. Si vous utilisez la (les) machines qui servent à fournir la puissance de calcul nécessaire à vos EJB pour faire tourner une autre instance de votre SGBDR, avec une réplication entre chaque instance du SGBDR, et un load balancer tout simple, vous vous en sortirez bcp mieux et bcp plus simplement.
EJB c'est un bon modèle, mais c'est pas une panacée. C'est *PARFOIS* utile, tout comme un moniteur transactionnel est *PARFOIS* utile.
Il faut toujours garder une chose en tête, pour savoir douter :
- L'intérêt de SUN est de rendre les clients dépendants d'eux (alors qu'avant ils ne l'étaient pas).
- L'intérêt de SUN est de vendre des machines.