Dekuji za odpoved.
Optimisticke zamikani vypada docela slibne. Nicmene vezmneme nasledujici
priklad. Objekty v mem systemu se radi do samostatnych stromu. Techto
stromu bude docela malo v pomeru s tim jak jsou velike. Zamykat jenom
podstromy by bylo dost slozite, takze budu muset zamykat koren.
Pouziji-li optimisticky lock znamena to ze si dva uzivatele budou moci
soucasne otevrit ten samy strom a pracovat v nem
(pridavat/prohlizet/menit/mazat listy), ale zmeny se podari ulozit jenom
tomu kdo jako prvni klikne save a commitne svoji transakci. Druhemu
uzivateli by pak bylo sdeleno ze jeho zmeny nelze ulozit.
Z tohoto duvodu me prijde schudny jedine pesimisticky pristup. Nicmene
stale premyslim jak to implementovat a jedine co me napada pridat do DB
sloupecek ktery bude zamek identifikovat a tim se ridit. Dalsi problem
vidim v trvanlivosti takovychto zamku a taky jak zajistim ze v jine
session nedojde k nejake chybe a zamek se neuvolni. Je periodicke
obnovovani zamku spravne reseni?
Dik moc.
Honza
Jiří Melichna napsal(a):
Zdravim,
pochopitelne pesimisticke zamykani zaznamu je jednou z moznosti, dalsi
moznosti resici zmineny problem konkurence je verzovani zaznamu
(optimisticke rizeni konkurence, kdy se predpoklada, ze nejsou v DB
horka mista). Pro pesimisticke zamykani zaznamu musi byt podpora jak na
strane DB (napr. FOR UPDATE v Oracle) tak na strane frameworku. Pro
reseni verzovani postacuje podpora na urovni frameworku a domnivam se,
ze DB nemusi ani podporovat transakce.
Napr. hibernate zcela jiste umi lock, ktery se pro jiz zmineny Oracle
prepise dotaz na SELECT ... FOR UPDATE. U nekterych EJB kontejneru
(napr. BEA nebo OC4J) je mozno tento princip vynutit nastavenim a
prekryt tak defaultni chovani s opakovanym nacitanim zaznamu, ktere ma
podle me v teto oblasti urcite mezery.
Doufam, ze jsem nastinil alespon neco, doporucuji kouknout na Hibernate
dokumentaci a pripadne zdrojove kody. Na nekolika projektech jsem
Hibernate celkem ke sve spokojenosti pouzil, ale jen jednou jsem se
setkal s verzovanim. Vetsinou jsem prave pouzival lock vzhledem k tomu,
ze vetsinou jsem pracoval s Oracle nebo jinou DB s podporou tohoto
mechanismu. Mel jsem ovsem nekdy vykonove problemy a musel jsem vytvorit
pokud mozno strategii, kdy se zamykal vzdy jen nejaky vstupni radek a ne
radky ve vsech tabulkach, ktere dohromady daji konkretni instanci...
JM
------------ Původní zpráva ------------
Od: Honza <[EMAIL PROTECTED]>
Předmět: Synchronizace persistentnich objektu
Datum: 04.10.2006 21:50:28
----------------------------------------
Zdravim,
muj dotaz se primo netyka Javy, ale spise navrhu aplikaci. Doufam ze
neni prilis off-topic.
Jak se ve viceuzivatelskem prostredi resi sychronizace a zamykani
persistetnich dat?
At uz pisu dvou nebo tri vrstvou aplikaci, vzdycky se nakonec potkam s
problemem, kdy si jeden uzivatel vyzada nejaky objekt (ktery v DB
reprezentovan nekolika zaznamy v ruznych tabulkach) a tento objekt
upravuje nebo prohlizi.
V pripade, ze s timto objektem bude chtit pracovat i jiny uzivatel,
tak mu musim zmeny na takovemto objektu zakazat (zamek uz vlastni jiny
uzivatel).
Jedna se o klasickou situaci read/write zamku branici vzniku
inkonzistentnich dat. Read zamek muze mit kdokoli. Write zamek muze
mit jen jeden.
Napadlo me nekolik zpusobu reseni, ale zadny jsem si zatim nedokazal
obhajit jako zivota schopny (na mapovani objektu DB-Java pouzivam
vlastni knihovnu). Resi nektere opensource frameworky tuto
problematiku? Resite ji vy ve svych aplikacich? Jak?
Predem velice dekuji za jakekoly ohlasy.
Honza
__________ Informace od NOD32 1.1791 (20061005) __________
Tato zprava byla proverena antivirovym systemem NOD32.
http://www.nod32.cz
