🚀 go-pugleaf

Adam K. wrote:
> Witam,
> Użytkownik "Sławomir Szyszło" <slaszysz@CIACHTOlist.pl> napisał w 
> wiadomości news:h2tt2q.2lk.1@slaszyszCIACHTO.list.pl...
>> Dnia Mon, 6 Jul 2009 21:51:01 +0200, "Adam K." <akobylin@nospam.op.pl>
>> wklepał(-a):
>>
>>> Chyba jednak nie, gdy rozpoczne transakcje w trybie read commited, 
>>> wykonam
>>> insert do bazy (nie wiem czy to ma znaczenie, ale dodawanie przy pomocy
>>> procedury skladowanej), to póki nie zrobie COMMIT/ROLLBACK inny 
>>> proces nie
>>> moze odczytac zadnych rekordów z tabelki.
>>
>> Odczytać może, ale nie te wstawione. ;)
> 
>>
>> Napisz może co masz na myśli tu:
>> "Podczas tego importu chciałbym aby baza w zakresie danych przed 
>> rozpoczęciem
>> importu była dostępna dla pozostałych użytkowników."
>>
>> Import oznacza dodanie danych, aktualizacje czy usuwanie? A może mix tego
>> wszystkiego?
>>
> 
> Import danych oznacza:
> 1. Usunięcie części danych
> 2. Dodanie brakujących
> 2. Modyfikacji (aktualizacji) części rekordów już istniejących.
> 
> Chciałbym osiągnąć taki efekt, że jeśli przed rozpoczęciem importu 
> tabelka Produkty miała np. 10 rekordów, to do zakończenia importu (czyli 
> wykonania COMMIT) pozostali użytkownicy widzą te rekordy niezmienione.
> Import część z tych rekordów usunie, część zmieni a część zmodyfikuje, w 
> rezultacie czego np. w tabeli pozostanie 5 rekordów niezmienionych, 3 
> zostaną skasowane, 2 zmodyfikowane, a 5 zostanie dodanych całkiem 
> nowych. Tak przygotowane rekordy wystarczy jeśli będą dostępne po 
> wykonaniu COMMIT.
> 
> Problem w tym, że jeśli mam READ_COMMITED, to do czasu wykonania COMMIT, 
> jakikolwiek SELECT z tabelki Produkty "zawiesza" się. Jeśli w określonym 
> czasie dotrze do serwera COMMIT, SELECT innego usera się wykona (zobaczy 
> on tabelkę już po zmianach), jeśli natomiast nie zdąży - klient 
> wykonujący SELECT z tej tabeli otrzyma wyjątek "Limit czasu 
> przekroczony" zamiast pobrać rekordy, które były dostępne przed 
> rozpoczęciem transakcji.
> Oczekiwany efekt do tej pory udało mi się osiągnąć tylko przy poziomie 
> izolacji transakcji typu SNAPSHOT...
> 
> Mam nadzieję, że teraz jest już jasne z czym mam problem :)
> 
> Pozdrawiam
> 
> Adam
> 

Jedyne wyjaśnienie dlaczego tak się dzieje, jakie przychodzi mi do głowy, to 
takie, że aplikacja używa pojedynczego połączenia do bazy danych, zarówno dla 
importu jak i dla użytkowników. Wtedy rzeczywiście jeśli połączenie jest zajęte 
przez transakcję importową inne polecenia wydane na tym połączeniu "zwisną". 
Jeśli tak nie jest to nie wydaje mi się, aby opisane zachowanie było możliwe. 
Podstawą w bazach danych jest możliwość jednoczesnego dostępu do danych przez 
wielu użytkowników. A takie zachowanie oznaczało by to, że na raz z bazą może 
pracować dokładnie jedna osoba.

Pozdrawiam

Sebastian