Deux utilisateurs modifient le même enregistrement en même temps. Comment empêchez-vous l'un d'écraser l'autre en silence ?

Utilisez le verrouillage optimiste dans la plupart des cas : donnez à la ligne une colonne de version ou un horodatage, incluez-la dans le prédicat de l'update, et si zéro ligne est modifiée, l'enregistrement a changé sous vos pieds, donc vous renvoyez un conflit. Utilisez le verrouillage pessimiste, un select for update dans une transaction courte, quand les conflits sont fréquents ou que l'opération ne peut pas être rejouée sans risque. La seule chose à ne pas faire est de lire, modifier et écrire sans aucune vérification.

L'échec, c'est le lire-modifier-écrire, où les deux requêtes chargent la version un, calculent toutes les deux à partir de données périmées et la seconde écriture gagne en silence. Ma correction par défaut est optimiste : chaque ligne a une version, l'update dit where id égale ceci et version égale ce que j'ai lu, et il incrémente la version. Si l'update signale zéro ligne modifiée, quelqu'un est arrivé avant moi et je renvoie un 409 au lieu de faire comme si ça avait marché. Ça ne coûte rien quand les conflits sont rares, ce qui est le cas d'habitude. Je passe au verrouillage pessimiste quand la contention est réelle ou qu'une reprise est inacceptable, par exemple pour décrémenter un stock, où je prends un select for update sur la ligne, je fais la vérification et l'écriture dans une transaction courte, et je ne garde aucun appel réseau dans cette transaction. Ce qui m'importe le plus, c'est ce que voit l'utilisateur. Une erreur de conflit brute ne sert à rien, donc pour un éditeur de documents on renvoyait la version courante à côté de l'erreur pour que le client puisse afficher un diff au lieu de simplement perdre le travail.