[Javalist] Adatbázis lock
Istvan Verhas
istvan at verhas.com
2012. Sze. 14., P, 13:37:52 CEST
Ezt úgy szokás megoldani, hogy van egy erre a célra dedikált oszlopod legyen a neve most lockedby ami NULL értékű ha senki nem foglalkozik az adott rekorddal. Minden kliensnek van egyedi azonosítója amivel kitölti ezt az oszlopot ha lockolni akarja azt a recordot. Ezt úgy teszi meg, hogy update-eli a saját id-val majd select-ál a saját id-ra, hogy tényleg sikerült-e illetve neki sikerült-e update-elni. Amikor kész van akkor pedig ismát NULL-ra update-eli. Biztos van neki szép neve is de azt nem tudom.
Egyébként működik ez akkor is ha egyszerre nem egy hanem több rekordot is szeretnél lockolni.
Verhás István
JIRA szakértő
Verhás & Verhás Szoftver Manufaktúra Kft.
istvan at verhas.com
t: +36(30)3997117
skype: verhasi
On Sep 14, 2012, at 1:26 PM, Vig, Balázs wrote:
> Ezt tudom, de ha lefut az update (márpedig több commit is van), akkor utána a várakozó update is lefut. Vagyis nem sikerült eltiltanom a másik klienst a sor kezelésétől, csak feltartottam egy kicsit.
>
> Üdv:
> Vig Balázs
>
>
> 2012. szeptember 14. 12:59 Keresztes Jozsef írta, <jkeresztes at vati.hu>:
> ÁLLJ !
>
>
>
> Ha egy sorra kiadsz egy UPDATE-et azt a sort automatikusan lock-olja az adatbázis, addig nem tud vele senki szórakozni amíg egy commit vagy rollback-et végre nem hajt az eljárásod. Ez teljesen automatikus, próbáld ki.
>
>
>
> Joe
>
>
>
> From: Vig, Balázs [mailto:balazs.vig at datasolutions.hu]
> Sent: Friday, September 14, 2012 12:56 PM
> To: Java lista
> Subject: Re: [Javalist] Adatbázis lock
>
>
>
> De nekem row lock kell: csak az adott sorral ne szórakozzon senki, a többi sort lehet szerkeszteni.
>
> Most azon gondolkodom, hogy oracle alatt a dbms_lock-kal létrehozok egy lockot: myapplock[rowid] néven, és amikor másik session akar lokkolni, akkor ellenőrzi az ilyen id-jű foglalás meglétét: ha nem sikerül lokkolni, akkor keressen magának másik elfoglaltságot ;)
>
> Egy-egy folyamat percekig is eltarthat (extrém esetben órák), ilyenkor fontos, hogy azért más feladat tudjon haladni. Mivel ilyen hosszú időről beszélünk, és a folyamat közben lehet (van) commit is, ezért nem állíthatom be, hogy a tranzakció végén automatikusan oldja a lokkot, azt nekem kell manuálisan a folyamat végén. Ez OK, de mi van akkor, ha egy kliens elszáll? Ilyenkor a lock megmarad, de nem lesz senki, aki feloldja. Tehát kell valami takarító mechanizmus is....
>
> Vagy simán csak megmondom, hogy egyszerre csak egy klienst futtassanak? ;) (nem kéne...)
>
> Üdv:
> Vig Balázs
>
>
>
>
>
> 2012. szeptember 14. 12:15 Keresztes Jozsef írta, <jkeresztes at vati.hu>:
>
> Vagyis konkrétan ezt kell csinálni:
>
>
>
> lock table szemafor in exclusive mode;
>
> update table_a …;
>
> insert into table_b …;
>
> …
>
> commit;
>
>
>
> Jelöljetek ki egy táblát (a példában “szemafor”), de lehet máshogy is…
>
>
>
> Joe
>
>
>
>
>
> From: Vig, Balázs [mailto:balazs.vig at datasolutions.hu]
> Sent: Friday, September 14, 2012 12:05 PM
> To: Java lista
> Subject: [Javalist] Adatbázis lock
>
>
>
> Sziasztok!
>
>
>
> Van egy Hibernate alapú kliensem, ami több példányban is futhat. A kliens feladata, hogy az adatbázis objektumokon műveleteket végezzen.
> Hogyan lehet azt garantálni, hogy egy objektummal csak az egyik kliens foglalkozhasson: ha az egyik már elkezdett dolgozni rajta, akkor másik már ne tudjon.
>
> Támogatja-e ezt valahogy a hibernate, vagy a jdbc? (eddig nem találtam erre semmit). Vagy nekem kell valami mókolnom az adatbázisban?
>
> Üdv:
> Vig Balázs
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20120914/427b8dac/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3015 bytes
Desc: not available
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20120914/427b8dac/attachment.p7s>
További információk a(z) Javalist levelezőlistáról