Witajcie.
Jakie są Wasze pomysły lub sprawdzone rozwiązania realizacji zagadnienia pt. "ten rekord jest już edytowany przez innego użytkownika".
0
3
Po pierwsze lektura nt "optimistic locking" i "pesymistic locking"
Obie mają zady i walety.
W optymistycznym pojawia sie pole timestamp (niekoniecznie taka implementacja w bazie, raczej zwyczajowa nazwa), można z niego to i owo wyciągnąć.
0
Tak lektura tych zagadnień już była. Przyjmijmy pesymistic locking lecz kwestia zerwania połączenia z bazą, przerwania edycji danych przez użytkownika (nieoczekiwanie)
dokładnie takie sytuacje, zastanawiam sie jak to sensownie rozwiązać
0
artbski napisał(a):
Tak lektura tych zagadnień już była. Przyjmijmy pesymistic locking lecz kwestia zerwania połączenia z bazą, przerwania edycji danych przez użytkownika (nieoczekiwanie)
Lub pójścia do kibla, potem coś zawróciło ...
Z mojej własnej perspektywy pesymistiuc jest (jak zauważasz) zbyt twardy na wiele życiowych scenariuszy (opis na blogu, faktura, PROSTE dokumenty). Osobiście wydaje byłby uzasadniony jedynie w jakiś ważnych życiowych sprawach 1)
Po drugie (trochę?) źle się sprzęga z filozofią aplikacji webowej, kolejny request z tej samej sesji zwykle trafi na inne połączenie SQL, czyli sam dla siebie będzie konkurentem (lepiej się sprawdzał w destopach)
Nie należy się bać optimistica. Choć zależy o jakich danych mowa, i jakie prawdopodobieństwo konfliktu. Zawsze trzeba to ergonomicznie obudować w UI.
- a na ważne życiowe sprawy i tak bym robił jakiś middle-ware (Java / C#, tam przebywam)
0
Chodzi konkretnie o aplikację typu ERP (np. faktury) z interfacem webowym.
1
artbski napisał(a):
Chodzi konkretnie o aplikację typu ERP (np. faktury) z interfacem webowym.
Tak często - wręcz na wyścigi - ludzie babrają w starych, już istniejących fakturach?
Bo przecież (w sensownym projekcie) nie dotyczy to nowej faktury
0
Nie chodzi o częstotliwość i wyścig. Chodzi o wielodostęp i niemożliwość jednoczesnego edytowania przez wielu użytkowników tego samego dokumentu.
Jest wiele takich przypadków mniej lub bardziej uzasadnionych aczkolwiek są. Systemu zawsze musiały i będą musiały być głupoodporne.
0
artbski napisał(a):
Nie chodzi o częstotliwość i wyścig. Chodzi o wielodostęp i niemożliwość jednoczesnego edytowania przez wielu użytkowników tego samego dokumentu.
Jest wiele takich przypadków mniej lub bardziej uzasadnionych aczkolwiek są. Systemu zawsze musiały i będą musiały być głupoodporne.
W dobrym ERP szycie tego na poziomie faktury, bez żadnych uprzednich decyzji architektonicznych, bez seniorów itd ...
0
Jeśli możesz odnieść się merytorycznie do tematu to bardzo proszę jeśli nie to nie nabijaj sobie kosztem tego postów. To nie ma sensu, aczkolwiek taka niestety jest rzeczywistość na forach i nie spodziewałem się więcej.
3
Korzystasz z jakiegoś frameworka, czy piszesz w czystym PHP?
Możesz dodać do tabeli z rekordami kolumny typy lock_time, user_id. Przy wejściu na rekord zapisujesz id usera i czas. Po jakiejś akcji zakończenia działań czyścisz te wpisy. Dodatkowo ustawiasz task w systemie który czyści jakieś locki po określonym czasie na wypadek dłuższej lub nieskończonej przerwy.
Od cała filozofia. Można to nazywać podejściem pesymistycznym ale z tego co piszesz czegoś takiego potrzebujesz.
0
Korzystam z frameworka Codeigniter z modyfikacjami dla własnych potrzeb. Większość frontendu w javascript. Rozpatrywałem już chyba wszystkie możliwe podejścia do tego tematu i w zasadzie napisałem ten post po to właśnie, aby dowiedzieć się jakie Wy stosujecie rozwiązania tego tematu. To o czym piszesz wydaje mi się właśnie najbardziej sensowne do tego celu. Uruchomienie crona i zdejmowanie ewentualnych blokad po określonym czasie.
2
Ile przypadków tyle rozwiązań. Np w przypadku wykrycia ze dokument sie zmienil w miedzyczasie wywalasz uzytkownikowi error sorry ale dokument sie zmienil zacznij prace od nowa :).
1
Ja tak w kilku systemach robiłem. Działa, pozwala wyświetlić komunikat typu: użytkownik z edytuje rekord itd.
To co opisuje @Schadoow też jest jakimś podejściem, ale osobiście nie preferuję wkurzania użytkowników.
0
Tak dokładnie, jeśli cron usunie z tabeli "lock" dla użytkownika w danej sesji na konkretnym rekordzie, wówczas podczas próby zapisu formularza pojawi się stosowny komunikat "że sorry".
Natomiast sensownym byłoby również uruchomienie funkcji podtrzymującej (przedłużającej) czas blokowania. Wówczas aktywnego (powolnego w swej pracy) użytkownika nie spotkałaby niemiła niespodzianka.
1
Ja po prostu dobieram czas empirycznie i ustawiam takie taaki na 15 czy tam 30 minut. Nie miałem tak długich działań użytkowników per rekord żeby taki czas przedłużać. Ale to już musisz sam zweryfikować.
0
Jakby nie było, integralność danych jest istotniejsza niż poziom niezadowolenia użytkownika :-)
3
@jurek1980: zresztą co za problem dać ten czas jako parametr, który admin danej instalacji może zmienić, jak okaże się, że 15 minut to za mało dla Bożenki z księgowości albo Miecia z zaopatrzenia?
0
Moi użytkownicy potrafią wprowadzać fakturę ponad 2 godziny i nie dlatego, że są powolni, ale dlatego że faktura ma ok 1000 pozycji... - Panczo 51 minut temu
Problem z lockiem dotyczy tylko "starych" faktur (chyba, ze projekt leży i kwiczy)
0
Fakt - dotyczy to dokumentów już wystawionych i poddanych edycji. Natomiast dla uściślenia nie dotyczy to li tylko dokumentów typu "faktura". To tylko przykład dla zobrazowania jakiego rodzaju danych dotyczy to zagadnienie. Edycja pojawia się również w przypadku dokumentów typu "raport bankowy", "raport kasowy", etc. etc. a "rozjazd" danych np. rozrachunkowych i późniejsze ich uzgodnienia nie należą do przyjemnych historii.
1
artbski napisał(a):
Fakt - dotyczy to dokumentów już wystawionych i poddanych edycji. Natomiast dla uściślenia nie dotyczy to li tylko dokumentów typu "faktura". To tylko przykład dla zobrazowania jakiego rodzaju danych dotyczy to zagadnienie. Edycja pojawia się również w przypadku dokumentów typu "raport bankowy", "raport kasowy", etc. etc. a "rozjazd" danych np. rozrachunkowych i późniejsze ich uzgodnienia nie należą do przyjemnych historii.
W tej kategorii, i przez słówko ERP, to oczekiwany jest mechanizm np śladu rewizyjnego (zapis do inteligentnego loga)
Wyżej koledzy wskazują na 'lock' m.in. z identyfikacją użytkownika.
Wydaje mi się, ze ta grupa (pewnie w niej mieści się więcej zazębiających się zagadnień) powinna mieć wspólny projekt, być jednym z filarów ERP.
Edycja pojawia się również w przypadku dokumentów typu "raport bankowy", "raport kasowy", etc. etc. a "rozjazd" danych np. rozrachunkowych i późniejsze ich uzgodnienia nie należą do przyjemnych historii.
Nie wyobrażam sobie bez middle-ware, na surowej bazie SQL. Oczywiście nie zaniedbując wszelki reguł integralności SQL, ale SQL to za mało (szkolny przykład: nie da się zrobić granta do niektórych wiersz tabeli, albo granta warunkowego)
0
Lock możesz odświeżać jeśli sesja jest aktywna (użytkownik coś robi).
Jeśli nie jest aktywna, przestajesz odświeżać timestamp i demon łapie taki stary lock i usuwa.
Do tego blokada optymistyczna.
5
jurek1980 napisał(a):
Ja tak w kilku systemach robiłem. Działa, pozwala wyświetlić komunikat typu: użytkownik z edytuje rekord itd.
To co opisuje @Schadoow też jest jakimś podejściem, ale osobiście nie preferuję wkurzania użytkowników.
No zawsze można ich nie wkurzać, po prostu nie zapisać zmian z przestarzałej kopii. Albo odwrotnie - ostatni wygrywa.
Tak czy siak, to nie ma sensu zadawanie tego pytania na tym forum, bo to nie jest kwestia techniczna tylko biznesowa.
4
@somekind: to jest głównie kwestia biznesowa, ale OP chyba dostał właśnie takie zadanie. Rozważając za i przeciw w jakiejś dyskusji warto zawsze wspomnieć, że wtedy jeden użytkownik może być niezadowolony. Ot cała idea tego mojego postu.
2
Nasz najlepszy w Polsce ERP jest projektowany na postawie opinii z forów internetowych
prawda, że tego jeszcze w marketingu nie było?