Je ne vois aucune portée de transaction explicite dans votre code, donc je ne sais pas quels verrous sont déjà en place lorsque vous effectuez votre mise à jour ; de plus, le niveau d'isolation que vous utilisez n'est pas clair. Mais le scénario le plus courant dans ce type de situation est que plus tôt dans la même transaction, vous avez émis un select (verrou de lecture) sur les mêmes lignes que vous essayez de mettre à jour plus tard. Cela entraînera une escalade de verrous et peut entraîner un blocage si deux transactions tentent de faire la même chose :
- Transaction A :sélectionnez avec un verrou de lecture
- Transaction B :sélectionner avec un verrou de lecture
- Transaction A :mise à jour :souhaite transformer son verrou en lecture en verrou en écriture, mais doit attendre que la transaction B libère son verrou en lecture
- Transaction B :mise à jour :souhaite transformer son verrou en lecture en verrou en écriture, mais doit attendre que la transaction A libère son verrou en lecture.
Bingo ! blocage car A et B attendent l'un l'autre pour libérer leurs verrous de lecture existants avant de pouvoir effectuer leur mise à jour.
Pour éviter cela, vous avez besoin d'un indice de verrouillage dans votre sélection, par exemple,
select * from table with (updlock) where blah blah
Cela garantira que votre sélection utilise un verrou en écriture au lieu d'un verrou en lecture, ce qui empêchera l'escalade du verrou entre les transactions simultanées.
