ObjeckLocking u multi-klijent arhitekturi

Struktura je sledeca: postoji nekoliko (ogranicen broj) klijenata koji koriste svoju instancu odredjene aplikacije i svi su medjusobno dostupni zbog komunikacije. Baza podataka je centralizovana.
Zahtev je sledeci: spreciti da vise od jednog klijenta istovremeno vrse specificiranu operaciju nad istim objektom (objekat je definisan ID-em iz baze).

Kako najelegantnije i najsigurnije resiti ovaj problem? Pricamo teoretski, bez ulazenja u konkretne tehnlogije. Pod terminom "klijenti" mogu biti i web serveri unutar load balancer-a, desktop aplikacije medjusobno dostupne online...


Ono sa cim sam ja trenutno izasao kao privremenim resenjem:
- svaki klijent vodi listu/tabelu ID-eva koje trenutno drzi zakljucanim
- svaki klijent ima i listu "lokacija" ostalih klijenata
- prilikom zahteva za izvrsenje specificirane operacije najpre proverava svoju tabelu, a zatim i tabele svih ostalih klijenata.
- ukoliko objekt nije zakljucan, klijent ga zakljucava u svojoj lokalnoj listi i nastavlja sa operacijom

Najvecu manu gore navedenog algoritma vidim u mogucem dugom cekanju na odgovore ostalih klijenata.

Centralizovano vodjenje liste svih zakljucanih objekata, u bazi, bi donelo minimum utrosenog vremena ali nisam siguran da je moguce odrzati takvu listu azurnom usled mogucih "otkaza" klijenata. Kako onda azurirati listu oslobadjanjem objekata klijenta koji vise nije dostupan? Uvesti dodatni proces/aplikaciju koja na zadate intervale proveravati listu i dostupne klijente? Itd, itd...

Problem je suviše generalno postavljen, tako da je teško dati odgovor.

Klijentske i web aplikacije se vrlo mnogo razlikuju. Na primer, u klasičnoj web aplikaciji, transakcije su kratke i obično submit radi i upis u bazu, dok klijentske aplikacije obično znatno duže "drže" objekt u bazi. Dalje, web konekcije su obično deljene između web klijenata dok su desktop konekcije ekskluzivne itd.

Iz mog iskustva, uvek je bolje koristiti ono što nudi baza nego praviti komplikovanu logiku, naročito ako logika već postoji u bazi.

Na primer, može se koristiti default locking mehanizam baze - uraditi dummy update sloga koji se ažurira, a da se ne uradi commit. Sama baza će se pobrinuti da se lock skine sa objekta ako je sesija pala.

Dalje, u ORACLE bazi, koristim DBMS_LOCK paket da bih implementirao eksplicitno lokovanje nekog objekta, umesto da implementiram svoje sopstveno rešenje.
Sledeći pristup je da se napravi "dispečer" poslova koji će biti zadužen da delove posla raspoređuje na klijente. Pristup poslovima (i objektima u bazi) tada klijenti dobijaju od dispečera, a on na jednom mestu održava konkuretnost pristupa. Ovaj pristup koristimo i kod mene u firmi za paralelizaciju poslova, uz, na primer, mehanizam Advanced Queues.

U oba primera koriste se napredne mogućnosti koje ima baza sa kojom radim, jer je zdravorazumska pretpostavka da RDBMS usluge treba radije koristiti (bolje optimizovane, na nižem nivou itd) nego praviti specijalna rešenja.

Da malo konkretizujem: u pitanju su web aplikacije, ali koje drze i obradjuju jako dug vremenski period odredjeni resurs (neretko ~1h) pa samim tim imaju i potrebu da zakljucaju objekt u bazi koji je u vezi sa tim resursom. Tako da i nisam siguran u koju bi "grupu" smestio ovakvu aplikaciju.

Ovo zvuci kao potencijalno sjajno i cisto resenje. Moze li neki dodatni info ili link, da ne bih izmisljao vec izmisljeno.

Pa mislio sam na situaciju da se uradi nešto kao sledeće:
1. na aplikacionom serveru se isključi AUTO_COMMIT. Na primer ovako nešto postoji u PHP-u, AUTO_COMMIT je po defaultu ON.
2. uradi se UPDATE MyTable set ID=ID where ID=MyID (uz pretpostavku da je ID primarni ključ tabele MyTable i da želimo obradu sloga sa ID MyID)
3. izvršava se neka obrada...
4. uradi se COMMIT

Pesimistic lock ne treba da koristis ni za sta sem u krajnjoj apsolutnoj nuzdi, a kamoli da drzis X lock na sat i nesto vremena (niti bi to dozvolio DB bez nekog zesceg hacka). Pribegavanje pesimistic lockovima za svaku glupost je znak lose arhitekture i loseg dizajna aplikacije

Ne postoji "fabricko" lock resenje za tvoj problem, uvek moze da ti se desi da se dva korisnika sudare u rezervisanju resursa isto kao sto mogu da se sudare i u update komandi. Ljudi to cesto zaborave i misle da lock rezervacijom u dugackim transakcijama resavaju problem (a sta je sa sledecim procesom koji ostaje blokiran dok se lock ne oslobodi?). Ono sto tebi treba je sistem rezervacije sa ili serijalizijom operacija ili sa optiimstic lockom.

1. Serijalizacija, napravis neki unattended servis koji barata objektima, njihovim rezervacijama i TTLovima. Svaki zahtev koji servis primi lokalno queue-jes i redom rezervises objekte klijentima. Queue ti je jedan od mehanizama serijalizacije, u principu mozes i neki drugi da koristis. Prosto postavi sebi pitanje sta se desava ako u apsolutno isto vreme dva razlicita klijenta izdaju identican zahtev. AKo znas sta se desva onda znas dal si resio konkurentnost.

2. Optimisitick lock rezervazija. Dodaj jos dva polja u tabelu objekta, clientID i TTL. Rezervaciju vrsis sa:

update objekat set clientid=mojID, TTL=vremeisticanja WHERE ID=objectid AND ClientID IS NULL

ovo bold je vazno. Ako se dva klijenta sudare svaki SQL ce ih serijalizovati po defaultu jer ce se sudariti na update row-locku, prvi ce proci i imati 1 row updated, drugi ce potom vratiti 0 rows updated (jer clientID vise nije null) i problem rezervacije je resen a nigde nije bilo X lockova i update lock je trajao najminimalnije moguce. Posle napravis neki server job koji ce periodicno (recimo svakih 60 sekundi) da uradi update clientid i TTL na null ako je istekao TTL (za one koji su ispali) a kad klijent regularno zavrsi rad moze sam da postavi svoju rezervaciju na null i gotovo.

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Nisam razmisljao da SQL serijalizuje upite i da zahtev za upis moze biti dovoljna informacija o lock-u. Odlicno. Ali TTL je ovde sporno. Jer procesi mogu trajati od 1min do preko sat vremena. Sta ako klijent "ispadne" nakon par minuta a TTL je postavljen na 2h? Izgubiti taj objekat na 2h? Mislim da registrovanje na svakih 60s da li je neki od klijenata ispao i osloboditi objekte koje je on zakljucao nije nista jevtinija operacija nego da svaki klijent ponaosob proverava liste zakljucavanja ostalih klijenata kada za to ima potrebu.

Opet malo konkretizacije: U ovom slucaju nema blokiranja procesa. Klijent ce samo dobiti poruku da je resurs zauzet i da pokusa kasnije. Naravno, uopsteno govoreci, blokiranje procesa do oslobadjanja lock-a jeste izrazito nepozeljno i problematicno.

Sto se tice "fabrickog" resenja - naravno da ne postoji, zato sam i postavio pitanje ovde da bih video kako se razliciti ljudi dovijaju :)

TO sad zavisi od poslovnih zahteva da li je tebi ili nije zgodno da drzis objekat rezervisan 2 sata. Ozbiljan problem koji ti imas je sto server ne moze realno da se zabavlja time da li su klijenti jos u zivotu (sto si i sam primetio), dodatno komplikovan time da ti neke klijente i ne mozes nikako da proveris (npr web user, za njega nikad ne mozes da znas zasigurno da li jos uvek unosi podatke ili je ugasio browser i otisao, a zbog toga sto je web stateless). Zato ti je TTL neophodan. Ono sto mozes da uradis je da minimizujes TTL na osnovu tehnicke prirode klijenta koji trazi rezervaciju. Npr ako je web klijent namesten da sesija istice za 20 minuta za te klijente trazi rezervaciju na 25 minuta i produzi je pri svakom callbacku web servera, za desktop aplikaciju rezervisi na 5 minuta pa svakih 3 minuta produzi rezervaciju, itd, nigde ne pise da svi klijenti moraju da dobiju rezervaciju pod istim uslovima i da rezervacija ne sme da se produzuje. Ako se web aplikacija ne javi za 25 minuta da produzi rezervaciju onda se nece javiti uopste jer joj je istekla sesija na serveru, zar ne ?
Najveci problem su ti iskreno stateless klijenti, njih jednostavno ne mozes da automatizujes nikako jer ne znas sta oni i kako rade.

PS: I da, SQL server ne serijalizuje upite, SQL serijalizuje update/insert po principu 'ko pre devojci njemu row lock'. Dobra stvar je sto ovo ne izaziva X (exclusive) lockove pa ce selecti drugih procesa nad tom tabelom raditi bez zastoja (sta ce vratiti naravno zavisi od izolacije).

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić