De curand am citit cartea "SQL Server™ 2005 Bible", scrisa de Paul Nielsen. La capitolul "Managing Transactions, Locking and Blocking" am intalnit urmatoarea informatie legata de proceduri stocate si shared locks. :
    "Be careful with shared locks. I believe that misused shared locks are a common cause of
    update-performance problems. Applications should grab the data in a way that doesn’t hold
    the shared lock. This is one compelling reason to use stored procedures to retrieve data."

Cum influenteaza procedurile stocate felul cum se obtine un shared lock? De ce acest lucru nu se intampla si la view-uri?

Nu cred ca SHARED LOCK are vreo legatura cu ideea de procedura storata in sine. Un query rulat dintr-o procedura sau unul dintr-un SQL dinamic (cel pe carel scrii in cod si-l trimiti la server) se comporta la fel raportat la lock-uri. Procedurile stocate prezinta alte avantaje cum ar faptul ca sunt precompilate si ca planurile de executie au sanse mai mari de a fi reutilizate de catre server.

Ma gandesc insa ca autorul se refera la urmatoare situatie: faci un SELECT folosind un IDataReader (de ex SqlDataReader), stai in bucla while(dr.Read()) si faci operatiuni de INSERT, UPDATE, DELETE in acceasi tabela, eventual pe aceleasi recorduri. SELECT-ul mentine un SHARED LOCK iar INSERT, UPDATE, DELETE ar vrea si ele sa faca un LOCK exclusiv pe aceleasi recoduri (sau pagini). In acest moment intr-adevar performnata I,U,D are de suferit, iar in unele situatii poate aparea DEADLOCK. Idee e sa eliberezi lock-ul cat mai repede posibil si asta se poate face daca incarci datele intr-o colectie de date (deconectata), dupa care poate urma orice alta procesare.

Daca afli pana la urma ce-a vrut sa spuna autorul, scoate-ma si pe mine din ceata.

---

Florin Cardasim