- Tabela pełni funkcję znacznika trwającej edycji: obecność wiersza oznacza, że ktoś właśnie pracuje na danym rekordzie.
- Klucz główny na kolumnie
REFNOgwarantuje, że jeden dokument nie może zostać zajęty przez dwie osoby jednocześnie. - Kolumny
LOGINiKIEDYpozwalają pokazać użytkownikowi, kto blokuje dokument i od jak dawna. - Wpisy osierocone po zerwaniu sesji trzeba usuwać cyklicznie — inaczej dokument pozostaje niedostępny mimo braku realnej edycji.
Do czego służy tabela [dbo].[_edit]
Gdy dwie osoby otworzą ten sam dokument i obie zapiszą zmiany, wygrywa ta, która kliknęła później — a praca pierwszej znika bez śladu i bez ostrzeżenia. Tabela [dbo].[_edit] zapobiega temu w najprostszy możliwy sposób: zapisuje, że dany rekord jest w tej chwili edytowany.
Mechanizm opiera się na kluczu głównym. Przy otwarciu dokumentu do edycji system próbuje dopisać wiersz z numerem referencyjnym rekordu. Jeżeli wiersz już istnieje, wstawienie się nie powiedzie i użytkownik zobaczy komunikat, że dokument jest zajęty. Po zapisaniu lub porzuceniu zmian wiersz jest usuwany, a rekord wraca do dyspozycji.
To rozwiązanie z rodziny blokad pesymistycznych — konflikt jest wykluczany, zanim powstanie, a nie wykrywany po fakcie. Jego zaletą jest przewidywalność: użytkownik dowiaduje się o zajętości przed rozpoczęciem pracy, nie po jej wykonaniu. Wadą — zależność od tego, czy blokada zostanie poprawnie zwolniona.
Kluczowy jest ostatni krok. Zerwana sesja nie usuwa wiersza, dlatego system potrzebuje mechanizmu sprzątającego wpisy pozostawione bez zamknięcia.
Budowa tabeli — wykaz kolumn
Cała informacja mieści się w trzech kolumnach — identyfikatorze blokowanego rekordu oraz danych o tym, kto i kiedy blokadę założył.
| Kolumna | Typ | Wymagana | Znaczenie |
|---|---|---|---|
KIEDY | datetime data i godzina | nie | Data i czas dodania rekordu - rozpoczęcie edycji |
LOGIN | varchar(50) tekst do 50 znaków | nie | Nazwa użytkownika kotry edytuje oryginaly zapis |
REFNO | bigint liczba całkowita 64-bitowa | tak | Identyfikator wiersza tabeli, odnosi sie do edycji dokumentu oryginalnego np refno, nridodn itp |
Kolumna REFNO przechowuje numer referencyjny rekordu z tabeli źródłowej. Ta sama wartość identyfikuje dokument w dzienniku zdarzeń i w rejestrze błędów, co pozwala powiązać blokadę z historią operacji.
Indeksy i wydajność zapytań
Tabela jest mała i odczytywana punktowo, ale jej indeks pełni rolę wykraczającą poza wydajność.
| Indeks | Kolumny | Rodzaj |
|---|---|---|
PK__edit | REFNO | klucz główny |
Klucz główny na kolumnie REFNO nie służy tu przyspieszeniu odczytu, lecz wymuszeniu reguły biznesowej: jeden rekord może mieć najwyżej jedną blokadę. Ochrona przed równoczesną edycją opiera się na tym ograniczeniu, a nie na sprawdzeniu w kodzie aplikacji — dzięki czemu działa także wtedy, gdy dwa zgłoszenia trafią do serwera w tej samej chwili.
Blokada pesymistyczna a wykrywanie konfliktu — dwa podejścia
Ochrona przed nadpisaniem zmian daje się rozwiązać na dwa sposoby, które różnią się momentem wykrycia konfliktu. StudioSystem stosuje pierwszy z nich dla dokumentów edytowanych długo i przez wiele osób.
| Cecha | Blokada zakładana z góry (tabela _edit) | Wykrywanie konfliktu przy zapisie |
|---|---|---|
| Kiedy użytkownik dowiaduje się o konflikcie | Przed rozpoczęciem pracy | Dopiero przy próbie zapisania zmian |
| Ryzyko utraty pracy | Brak — drugi użytkownik w ogóle nie zaczyna | Realne, jeśli zmian nie da się scalić |
| Zachowanie przy zerwanej sesji | Blokada zostaje, wymaga sprzątania | Bez konsekwencji |
| Obciążenie bazy | Dodatkowy zapis przy każdym otwarciu | Porównanie znacznika wersji przy zapisie |
| Sprawdza się przy | Długiej edycji dokumentów przez wiele osób | Krótkich, punktowych zmianach pojedynczych pól |
Kolumna STAMP typu timestamp, obecna w większości tabel StudioSystem, umożliwia zastosowanie drugiego podejścia tam, gdzie blokada byłaby zbyt uciążliwa.
Wybór nie jest przypadkowy. Dokument magazynowy z kilkudziesięcioma pozycjami wypełnia się kilkanaście minut i scalenie równoległych zmian nie miałoby sensu — tu blokada jest właściwa. Zmiana jednego pola w kartotece towaru trwa sekundy, a blokowanie całej kartoteki na ten czas utrudniałoby pracę bez realnej korzyści.
Jak korzystać z tabeli w praktyce
Przy utrzymaniu systemu z blokadami edycyjnymi liczą się przede wszystkim dwie rzeczy: czytelny komunikat dla użytkownika i sprzątanie wpisów osieroconych.
- Pokazuj w komunikacie o blokadzie wartość z kolumny
LOGIN— informacja „dokument edytuje Jan Kowalski” pozwala rozwiązać sprawę rozmową zamiast zgłoszeniem do administratora. - Uruchamiaj cyklicznie zadanie usuwające wpisy starsze niż ustalony próg, na przykład kilka godzin; to jedyna ochrona przed blokadami po zerwanych sesjach.
- Dobierz próg do najdłuższej realnej edycji w firmie — zbyt krótki spowoduje zdejmowanie blokad osobom, które nadal pracują.
- Przy ręcznym usuwaniu blokady sprawdź w dzienniku zdarzeń, czy użytkownik faktycznie zakończył pracę; przedwczesne zwolnienie przywraca ryzyko, przed którym mechanizm ma chronić.
- Nie zakładaj blokad na kartoteki edytowane punktowo — dla nich lepiej sprawdza się porównanie znacznika
STAMPprzy zapisie. - Monitoruj liczbę wierszy w tabeli; stały wzrost oznacza, że blokady nie są zwalniane i mechanizm sprzątający nie działa.
Zapytanie wskazujące blokady utrzymujące się nietypowo długo — kandydatów do sprawdzenia i ewentualnego zwolnienia:
SELECT REFNO,
LOGIN,
KIEDY,
DATEDIFF(MINUTE, KIEDY, GETDATE()) AS MINUT_TEMU
FROM dbo._edit
WHERE KIEDY < DATEADD(HOUR, -2, GETDATE())
ORDER BY KIEDY;
Przed usunięciem wierszy zwróconych przez to zapytanie warto sprawdzić w tabeli _sessionlog, czy sesje tych użytkowników są nadal aktywne.
Blokada edycyjna to mechanizm, którego użytkownicy nie zauważają, dopóki działa poprawnie. Zauważają go natychmiast, gdy zostaje wpis po awarii sieci, a dokument staje się niedostępny bez wyraźnego powodu — dlatego zadanie sprzątające jest tu równie ważne jak sama blokada.
Powiązane tabele i dokumentacja
Blokady edycyjne współpracują z rejestrami sesji i zdarzeń, które pozwalają ustalić, co działo się z dokumentem: