Blokada wierszy

0

Witam,

Potrzebuję zrobić blokadę wiersza podczas gdy na jego danych będą przeprowadzane procesy/obliczenia przez kilka dni. Z Waszego doświadczenia, jaką metodę najlepiej zastosować do tego typu? Blokada w transakcjach może okazać się słabym podejściem, gdyż przerwanie transakcji/połączenia skutkuje utratą tego, a przypominam, że blokada miała być trwać przez ładnych kilka dni.

0

Jeżeli połączenie zostanie przerwane, to jak długo ma jeszcze ta blokada się utrzymywać? W nieskończoność, czy jak ktoś opieprzy informatyka ;-)?

1

Odpiąć kabel sieciowy.

0

Miałem tu na myśli, nieoczekiwane zerwanie połączenia ;)

0

Ale tak ogólnie o co chodzi? Transakcja w SQL Serverze nie mają przecież limitu trwania, nie zakończy ich też odłączenie się aplikacji klienckiej.

Opisz problem dokładnie, napisz co chcesz osiągnąć, co to za dane, jakie operacje będą na nich wykonywane, czy będą wywoływane przez jednego klienta czy wielu, czy z aplikacji, czy np. z procedury składowanej, czy równolegle do przetwarzania mają być dostępne do odczytu przez kogoś innego, itd.

0
somekind napisał(a):

Ale tak ogólnie o co chodzi? Transakcja w SQL Serverze nie mają przecież limitu trwania, nie zakończy ich też odłączenie się aplikacji klienckiej.

No ale przecież utracenie połączenia z bazą danych (np. brak internetu itd) zakończy transakcje, czy się mylę?

somekind napisał(a):

Opisz problem dokładnie, napisz co chcesz osiągnąć, co to za dane, jakie operacje będą na nich wykonywane, czy będą wywoływane przez jednego klienta czy wielu, czy z aplikacji, czy np. z procedury składowanej, czy równolegle do przetwarzania mają być dostępne do odczytu przez kogoś innego, itd.

Będzie to tabela z wieloma danymi, liczbowe/tekstowe. W trakcie tych kilku dni, będzie związany z nimi proces przetwarzania, a więc będą odejmowane/modyfikowane pewne wartości, ale to się rozkłada w czasie. Dlatego przez ten czas nie może być w tym konkretnym wierszu nic ruszane przez WSZYSTKIE pozostałe osoby, dopóki aplikacja która zablokowała dany rekord z powrotem jego nie odblokuje. Operacje będą wywoływane z aplikacji. Odczyt równolegle może być możliwy przez inne osoby, ale brak możliwości edycji.

1

to dodaj sobie pole do tabeli zablokowane i po sprawie

0
abrakadaber napisał(a):

to dodaj sobie pole do tabeli zablokowane i po sprawie

Nie mogę tak, bo chcę zabiezpieczyć jakąkolwiek zmianę nawet z poziomu management studio czy zwykłego zapytania SQL

0

Zrob trigger ktory bedzie wyrzucal wyjatek przy jakielkowiek zmianie

0

jedyny wbudowany i pewny mechanizm na poziomie bazy to blokowanie przez transakcje. Możesz dodać trigger jak pisze @Georghinio ale jeśli obawiasz się, że ktoś będzie grzebał na poziomie SQLa to trigger też można wyłączyć

0
Krwawy Szczur napisał(a):

No ale przecież utracenie połączenia z bazą danych (np. brak internetu itd) zakończy transakcje, czy się mylę?

Niby czemu? SZBD nie obchodzi istnienie internetu, on dostaje zadanie do wykonania i będzie je wykonywał aż skończy. No chyba, że padnie zasilanie, powstanie deadlock i jakiś nadzorca ubije zablokowaną transakcję, albo klient wyśle żądanie przerwania. (Tak robią aplikacje dotnetowe, domyślnie po 10 minutach.)

Będzie to tabela z wieloma danymi, liczbowe/tekstowe. W trakcie tych kilku dni, będzie związany z nimi proces przetwarzania, a więc będą odejmowane/modyfikowane pewne wartości, ale to się rozkłada w czasie. Dlatego przez ten czas nie może być w tym konkretnym wierszu nic ruszane przez WSZYSTKIE pozostałe osoby, dopóki aplikacja która zablokowała dany rekord z powrotem jego nie odblokuje. Operacje będą wywoływane z aplikacji. Odczyt równolegle może być możliwy przez inne osoby, ale brak możliwości edycji.

A więc nie masz problemu technicznego lecz biznesowy. Rozwiązanie podał @abrakadaber, oznacz zablokowane przez aplikacje wiersze jakąś flagą, a po zakończeniu przetwarzania ją zdejmij.

Jeśli obawiasz się, że ktoś może modyfikować dane w bazie bezpośrednio, to jest to jakiś WTF - użytkownicy mają bezpośredni dostęp do bazy?!

1 użytkowników online, w tym zalogowanych: 0, gości: 1