🚀 go-pugleaf

Użytkownik "Adam K." <akobylin@nospam.op.pl> napisał w wiadomości 
news:h2ut2h$hli$1@news.onet.pl...
[...]
> 2. Uruchomiłem swoją aplikację, w niej rozpocząłem transakcję, dodawanie 
> rekordu (także bez commita), uruchomiłem na tym samym komputerze Microsoft 
> SQL Server Management Studio, podłączyłem się do tej samej bazy i 
> wykonałem SELECT * FROM tabelka, i to polecenie zawisło do czasu COMMIT w 
> mojej aplikacji.

Witaj w świecie rozległego blokowania rekordów ms sql... To niestety nie 
Oracle, gdzie transakcje blokują dane "normalnie", czyli jedna transakcja 
robi insert/update/delete, druga transakcja robi select i "widzi" stan 
rekordów sprzed rozpoczęcia pierwszej transakcji (oczywiście mowa o select 
"read only" bez klauzuli "for update").
MS SQL ma przykry zwyczaj blokowania większego obszaru danych, niż tylko 
rekordy objęte transakcją, przy czym chyba żaden dokument nie wyjaśnia 
dokładnie, jak wyliczyć blokowany obszar danych. Spróbuj w swoim teście 
zmienić select * from tab na select kolumna from tab where id=1 (przy 
założeniu, że rekord o id=1 istnieje i nie został objęty niezakończoną 
transakcją) i jest szansa, że dane zostaną pobrane.
Tu jest opisane http://msdn.microsoft.com/en-us/library/ms189849.aspx jakie 
"gradacje" blokad zna sql server, ale prawdę mówiąc wiele z tego nie 
wynika - nie oszacujesz ile stron zajmują rekordy w bazie...
Generalnie trzeba dążyć, żeby transakcja była możliwie najkrótsza; może 
droga zaproponowana przez Sławka jest dobra - czyli ładowanie wstępne danych 
do tabel specjalnie wydzielonych, z których nie korzysta aplikacja, tam 
obróbka, a potem tylko możliwie najprostszy insert/update tak, aby dane w 
tabelach wykorzystywanych przez aplikację były blokowane przez możliwie 
krótki okres czasu.
Izolacja transakcji na poziomie "snaphot" może pomóc, ale musiałbyś zmusić 
aplikację, aby też używała tego poziomu izolacji.

-- 
pozdrawiam,
Paweł Filipiak