Discussion :

[oliv37]

Bonjour,

Je suis confronté au problème suivant :

Prenons une appli web permettant de passer des commandes sur un produit :
Imaginons qu'on ait une méthode commanderProduit au sein d'une classe de service :

en pseudo-code cela donnerait l'algorithme suivant :

début commanderProduit

récupération du produit

si le produit a un stock > 0 {

on décrémente le stock du produit de 1 en BDD

on enregistre la commande en BDD

}

fin commanderProduit

Le problème est le suivant : nous avons 2 clients qui commande le produit en même temps et le stock est égal à 1.
2 threads accéderaient donc à cette méthode en même temps, ces 2 threads pourraient passer dans la condition stock > 0, au final le stock serait décrémenté 2 fois, ce qui est incorrect au niveau logique métier.

Rendre la méthode thread safe n'est pas une solution valable, cela ralentirait le temps de traitement dans le cas d'un grand nombre de connexions simultanées.
Une solution possible serait d'ajouter une contrainte sur le stock au niveau de la BDD, cela ferait échouer la transaction correspondant à la méthode passerCommande.

Quelle solution envisageriez-vous pour traiter ce cas de figure ? Comment gère-t-il cela sur les gros sites marchands ?

[thelvin]

Si tu utilises une BDD tu as pas trop le choix, tu dois compter sur ses contraintes ou transactions. (genre select for update de la ligne dont on veut modifier le nombre en stock.)

À noter que quand on a pas de BDD, bah la BDD elle fait pas de la magie, on peut faire une détection simple sans une trop forte contention, avec AtomicInteger par exemple.
Genre regarder le nombre N en cours avec get() et le mettre à N-1 avec compareAndSet(), et boucler pour réessayer tant que ça a échoué.
Ou juste faire decrementAndGet() et échouer si le nombre passe négatif, en refaisant incrementAndGet() pour annuler l'opération.

Comment gère-t-il cela sur les gros sites marchands ?

À ma connaissance :
- contraintes BDD,
- en réalité ils arrêtent de montrer en stock quand ils approchent de zéro, pas quand ils y sont, sauf article très mal vendu,
- e-mail "désolé il y a eu une erreur informatique, on ne va pas vraiment pouvoir honorer la commande <numéro>" au cas où tout a échoué. La certitude n'existe pas dans le monde réel.

[esired]

Bonjour.
En plus d'utiliser une contrainte sur la valeur de l'attribut stock, il serait plus intéressant de gérer la commande d'un produit par une procédure stockée qui prendrait en paramètre le code du produit, la quantité et le code du client. La procédure renverrait un code en fonction de la circonstance(OK, stock insuffisant, etc.) avec un message explicite. C'est bien mieux de laisser le SGBD gérer lui-même ce genre de situation, c'est la méthode la plus performante actuellement.
Les triggers sont aussi très utiles.

[oliv37]

Pour la procédure stockée, c'est une bonne idée. Par contre je ne suis pas un grand amateur des triggers, de mon vécu je trouve que les triggers n'aident pas à la maintenabilité du code, je préfère ne pas trop en abuser.