commit ou abbort d'une operation a la reception d'un message

commit ou abbort d'une operation a la reception d'un message - Divers - Programmation

Marsh Posté le 01-03-2010 à 02:22:51    

Bonjour,
 
Dans ce qui suit, je parle du problème sans spécification particulière de SGBD ou autre, je parle du concept en générale.
 
Supposons que j'ai une application qui s'exécute sur une machine A et qui fais une transaction locale sur cette dernière sans pour autant valider la transaction (commit). Je voudrais savoir est ce que c'est possible de faire en sorte que l'application se trouvant sur la machine A valide (commit) ou annule (abort) la transaction selon le message qu'elle reçois à partir d'une autre machine B (selon le message "VOTE-OUI" ou "VOTE-NON", respectivement).
 
Comment faire ça en générale ? Un exemple serait le bien venu (en utilisant n'importe quel langage ou SGBD).
 
Merci bien.

Reply

Marsh Posté le 01-03-2010 à 02:22:51   

Reply

Marsh Posté le 01-03-2010 à 10:06:08    

Citation :

sans spécification particulière de SGBD ou autre

Désolé, mais chaque SGBD fonctionne de manière un peu différente, et on pour généraliser il faudrait connaitre tous les SGBD possibles. Je n'en connais que trois ou quatre, donc je ne peux répondre que pour eux.
 

Citation :

valider la transaction (commit)

Qu'entendez vous par transaction ? habituellement il s'agit d'un ou plusieurs insert ou update. Le cas habituel est de ne faire qu'un seul insert ou update. Ce n'est que dans des cas assez rares, en pratique, que l'on doivent associer plusieurs insert et update. Pourriez vous préciser quel cas vous avez ? De plus, on peut utiliser des "select for update" dans certains cas, qui remplacent des transactions.
 

Citation :

la machine A valide (commit) ou annule (abort)

Une "validation" n'est pas toujours identique à un "commit". On peut valider en mémoire sans faire d'insertion. on peut valider en n'annulant pas.
De même une annulation n'est pas toujours identique à un "abort". On peut annuler en faisant une insertion inverse, etc.
 
En étant administrateur, on peut annuler ce que l'on veut.
 
Si l'on prévoit qu'une annulation sera possible, le plus simple est de commiter dans une table temporaire, et de transférer le contenu de cette table temporaire quand on sera sûr qu'il n'y aura plus d'annulation possible, ou bien d'utiliser le système des insertions inverses appelées aussi "contrepassations".


Message édité par olivthill le 01-03-2010 à 10:22:01
Reply

Marsh Posté le 04-03-2010 à 22:39:09    

Je crois que je ne me suis pas bien exprimé. Je parle ici d'une transaction distribuées. Voici un exemple du problème pour mieux comprendre ce que je veux faire:
Supposant que j'ai une machine client (C) et trois machines serveurs (S1, S2 et S3) connectées en réseau.

 

C lance un programme qu'on appellera Prg (un agent mobile par exemple) qui va se déplacer vers S1 et effectue une action A1, puis il se déplace vers S2 et effectue une action A2, et enfin il se déplace vers S3 et effectue une action A3, puis reviens a C.

 

Supposant que ces actions sont dépendant entre eux et donc que le client a besoin que toute les actions (A1 et 12 et A3) soit réalisés, ou aucune. Par exemple, si les actions A1, A2 et A3 représentent l'achat de 3 ingrédients 1, 2 et 3 pour faire un plat de cuisine, on n'aimerai pas qu'un ou plusieurs ingrédients ne soient pas achetés (exemple parce qu'il sont indisponible).

 

Ce que je veux faire maintenant est que par exemple dans le cas où le Prg passe par S1 et effectue son action A1 (achat d'ingrédient 1), puis quand il passe à S2 il n'arrive pas effectuer A2 vu qu'il n y a plu d'ingrédient 2 disponible ici. Alors dans ce cas il envoi un message "abort" au serveurs précédents qu'il a déjà parcouru (ici S1) pour abort l'action A1. Puis il retourne vers C et l'informe que c'est échoué.

 

Dans le cas où le Prg effectue A1, puis passe à S2 et effectue A2, puis passe à S3 et effectue A3, puis retourne vers C, ici il envoi un message "commit" à S1 et à S2 et à S3 pour leurs demander de commiter les actions A1, A2 et A3. Et dans ce cas la transactions distribuée constitué de A1+A2+A3 est effectué avec succès.

 

Bon ce n'est qu'un exemple simple pour illustrer ce que je veux faire.

 

La question est:
Est-ce que vous voyez que pour une action A qui dois être effectué sur un serveur x c'est mieux de faire en sorte que:
 - L'action A ne soit pas effectué dutout, mais plutôt sauvegarder en attendant de recevoir un message plus tard qui dira si l'action dois être effectué ou pas.
 - Ou bien effectuer l'action, puis selon le message reçu plus tard, on la commit ou abort.

 

Voilà.


Message édité par ssmr le 04-03-2010 à 22:39:41
Reply

Marsh Posté le 05-03-2010 à 06:57:38    

Et moi avec la méthode l'arrache je ferais un truc du genre :
Tu dis que tu réserves l'article sur S1 avec l'heure de réservation, tu vas sur S2, il y a pas, tu annules ta réservation sur S1.
 
Et tu as aussi un gardien qui va voir tous les articles réservés depuis 1h ou plus et qui les remets en rayon :')

Reply

Marsh Posté le 05-03-2010 à 09:43:16    

Il est préférable que le commit ou l'abort soit fait rapidement. Sinon les tables ou les fichiers de journalisation (que crée la base de données sans que le programmeur y pense) risquent de devenir énorme et de dépasser leur limite, ou de ralentir la machine à cause d'un swapping important. C'est l'une des raisons qui font que généralement, on a une validation postérieure par la mise à jour d'un flag et d'une date, ou bien une non-validation ou encore une annulation par un delete ou une insertion en sens inverse.

Reply

Marsh Posté le 05-03-2010 à 12:26:53    

olivthill a écrit :

généralement, on a une validation postérieure par la mise à jour d'un flag et d'une date, ou bien une non-validation ou encore une annulation par un delete ou une insertion en sens inverse.


Mais si l'action a besoin de faire une décrémentation d'un champ nbr_articles disponibles par exemple, je ne vois pas comment utiliser une validation postérieure par la mise à jour d'un flag.

Reply

Marsh Posté le 05-03-2010 à 15:39:16    

Il y a deux décrémentations possibles.
Une décrémentation virtuelle quand l'utilisateur n'a pas encore payé, et une décrémentation réelle quand il paye.

Reply

Marsh Posté le 05-03-2010 à 18:18:10    

olivthill a écrit :

Il y a deux décrémentations possibles.
Une décrémentation virtuelle quand l'utilisateur n'a pas encore payé, et une décrémentation réelle quand il paye.


Peut-tu me donner un exemple concret qui montre comment faire stp ? Parce que je vois un peut flou là.

Reply

Marsh Posté le 07-03-2010 à 13:55:16    

Moi je voudrais bien avoir des articles sur la contre passation :)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed