[Javalist] Adatbázis lock

[Istvan Verhas]

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>