Problème de concurrence avec UPDATE...SELECT sous forte charge

[david62]

Sur notre appli e-commerce, on a des deadlocks quand plusieurs clients commandent le même produit rare. La requête 'UPDATE stock SET qty=qty-1 WHERE product_id=X AND qty>0' bloque tout. Solutions ?

[sebastien75]

Classique ! Il faut isoler ta transaction en SERIALIZABLE ou utiliser SELECT FOR UPDATE. Mais attention aux perf.

[gigi57]

J'éviterais SERIALIZABLE, trop lourd. Opte plutôt pour des retries exponentiels avec backoff. Chez nous on utilise ce pattern avec un max_retries=3 et ça résout 99% des cas.

[antoine06]

Solution radicale : passe en optimistic locking. Ajoute un version_id que tu vérifies dans ton UPDATE. Moins de blocages mais besoin de gérer les échecs côté applicatif.

[david62]

Le SELECT FOR UPDATE marche bien mais ça ralentit tout quand il y a >100 req/s. Je vais tester le optimistic locking + retry. Vous avez un exemple concret en PostgreSQL ?

[sebastien75]

Pour PostgreSQL spécifiquement, regarde du côté des SKIP LOCKED. C'est parfait pour les files d'attente. Exemple : UPDATE ... WHERE id IN (SELECT id FROM stock WHERE ... FOR UPDATE SKIP LOCKED LIMIT 10)

[nerd42.r]

N'oubliez pas de vérifier vos timeouts (lock_timeout, statement_timeout). J'ai déjà vu des deadlocks qui duraient 30s par défaut...