Discussion :

[Sergejack]

Bonjour.

J'ai dernièrement achevé un développement lors duquel j'ai employé une technique sans doute fort originale mais dont je ne suis aujourd'hui pas encore convaincu du bien fondé.
J'utilise un SERVICE BROKER et ses messages pour éviter l'emploie de transactions lorsque certains query que je sais concurrents sont envoyés au serveur.

Je fais cela parce car sans transaction d'un niveau de contrainte assez élevé (REPEATABLE READ au minimum), des deadlock ou des (re)lectures sales pouvaient se produire mais hélas que l'acquisition de ces transactions étaient très coûteuses.
Maintenant, je bloque la "partie sensible" de mes queries (WAITFOR... RECEIVE...) tant que la pile de message reste vide et je place un message dans la pile dès que les queries sont sortis de leur "partie sensible".

En environnement de dev, ça fonctionne ainsi qu'en prod.
Mais je me demande si il n'y a pas un risque ou un contre coût que je sous-estime.

Vous en pensez-quoi ?

[SQLpro]

En principe SB n'est pas conçu pour travailler au sein du même serveur, mais pour faire des bases de données réparties sur plusieurs serveurs.

Effectivement c'est très intéressant car asynchrone quoique parfaitement transactionné ! En plus c'est fiables (tables) et sécurisé (privilèges + cryptage...).

J'ai mis en place cela à plusieurs reprise et cela permet de faire des architectures distribuées à haute tolérance.

Mais je pense que votre problème aurait sans doute pu être résolu autrement....

A +