Discussion :

[strompakha]

Bonjour,

Dans une application métier développée par java/javascript, nous avons une fonctionnalité qui permet d'annuler un ticket déjà créé (un ticket ici représente un droit d'achat dont le montant est soustrait du solde client). Donc l'annulation d'un ticket, quand elle est acceptée, rétablit le solde client avec le montant du ticket qui a été déjà soustrait.
Le problème c'est que pour des raisons de lenteur réseau, il se trouve que l'utilisateur clique sur le bouton annuler plusieurs fois et donc la requete d'annulation est envoyée plusieurs fois.
Ces requêtes multiples d'annulation (processus), sur le même ticket, passent sans problème (selon comment c'est développé aujourd'hui) et font que le solde du client est rétabli plusieurs fois ce qui lui donne plus de ce qu'il doit. Exemple: si on annule un ticket de 100 euros alors qu'on arrive à cliquer 3 fois sur le bouton annuler (sachant que le bouton annuler doit disparaître de l'écran dès le premier clique) alors le solde du client est augmenté de 3 x 100 euros au lieu de 100 euros.

Est ce que vous avez une idée de comment on peut verrouiller ce traitement de telle sorte qu'un seul process annulation puisse être exécuté?

Voici en bas la procédure stockée Oracle appelée lors du clique sur le bouton annuler d'un ticket donné. Le p_num_bordereau est l'identifiant d'un ticket.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Procedure annuler_ticket(p_num_bordereau IN VARCHAR2, NMES OUT NUMBER, LMES OUT VARCHAR2)
Is
 
V_ID_BORDEREAU NUMBER;
v_montant Number;
v_id_client number;
 
Begin
 
SELECT a.id_bordereau, montant, id_client
INTO v_id_bordereau, v_montant, v_id_client
FROM  chm.OPERATIONS a
AND a.numero_bordereau = p_num_bordereau;
--
DELETE FROM chm.operations
WHERE id_bordereau = v_id_bordereau;
--
Update chm.soldes set solde = solde + v_montant where id_client = v_id_client;
--
nmes := 0;
lmes := 'OK';
Exception
  When Others then
    nmes := 1;
    lmes := 'Ligne inexistante';
End;

[McM]

Bonjour,

Normalement le second devrait sortir en erreur 1 : Ligne inexistante, sauf s'il s'agit de 2 sessions différentes et un commit lointain.


Le mieux est de poser un verrou sur la ligne lors du SELECT, comme ça, tu es "sûr" que les autres sessions qui vont annuler le même p_num_bordereau vont attendre que le premier ait fini son commit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
PROCEDURE annuler_ticket(p_num_bordereau IN VARCHAR2, NMES OUT NUMBER, LMES OUT VARCHAR2)
IS
  v_id_bordereau number;
  v_montant number;
  v_id_client number;
BEGIN
 
  SELECT a.id_bordereau, montant, id_client
  INTO v_id_bordereau, v_montant, v_id_client
  FROM chm.OPERATIONS a
  AND a.numero_bordereau = p_num_bordereau
  FOR UPDATE;
 
  DELETE chm.OPERATIONS
  WHERE id_bordereau = v_id_bordereau;
 
  UPDATE chm.soldes set solde = solde + v_montant
  WHERE id_client = v_id_client;
 
  nmes := 0;
  lmes := 'OK';
EXCEPTION
WHEN Others THEN
    nmes := 1; lmes := 'Ligne inexistante';
END;

Pourquoi le where du DELETE ne correspond pas au SELECT ? Tu DELETE plus de lignes ?
Parce que du coup, le verrou sur 1 ligne et le DELETE sur plusieurs autres, tu peux avoir un interblocage, dans ce cas là, il faudrait poser un verrou NOWAIT sur toutes les lignes à DELETER
Je ne met pas le code, mais je peux le fournir si tu en as besoin.

[pachot]

Bonjour,
Le delete ne renvoit pas d'erreur lorsque la ligne n'est pas trouvée. Le nombre de lignes est dans SQL%ROWCOUNT
Il faudrait gérer une transaction avec savepoint et rollback. Genre: savepoint; update ; delete ; rollback if rowcount=0;

[McM]

Pourquoi tu voudrais faire si compliqué avec des savepoint et un update avant le delete ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
DELETE ..
IF sql%rowcount <> 0 THEN UPDATE END IF;

Mais tout dépend si la condition where du SELECT est la même que le DELETE ou pas.

[SQLpro]

Il suffit d'annuler la transaction si le nombre de ligne mis à jour dans la première requête est de zéro.

C'est le B A BA de la gestion des transactions !

1) pas de ligne mise à jour … que faire ?
2) erreur lors de la mise à jour … que faire ?

A +

[Scriuiw]

N'y a t-i pas un soucis dans la requête SELECT aussi ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT a.id_bordereau, montant, id_client
  INTO v_id_bordereau, v_montant, v_id_client
  FROM chm.OPERATIONS a
  AND a.numero_bordereau = p_num_bordereau

Sinon je rejoins les solutions à base de contrôle sur le SQL%ROWCOUNT qui doit aiguiller sur l'UPDATE ou non

[pachot]

Pourquoi tu voudrais faire si compliqué avec des savepoint et un update avant le delete ?

Parce que je vois un affreux 'when others' et j'ai peur que des modifications faites à moitié soient ensuite commit-ées.
Et que je trouve ça moins compliqué, de bien indiquer le début et la fin de ce qui est atomique. Et aussi de toucher au solde en premier.