Newsgroup: it.comp.java
Titolo: optimistic/pessimistic locking

ho +o- chiaro cosa siano ma li ho usati poco, nello specifico con
hibernate (a livello quindi di codice java) ho usato il pessimistic
locking su un update
ecco, ora mi chiedo: immagino che l'optimistic locking possa essere
gestito solo a livello java, insomma lanciando una query che lo
implementi, giusto? intendo dire che non è gestibile a livello del db
il pessimistic locking è invece forse (faccio delle supposizioni)
gestibile anche a livello del db anche se, come ho detto, l'unica volta
che l'ho usato è stato a livello di codice java
è corretto quel che dico? grazie
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 č corretto quel che dico? grazie
In linea di massima "ottimistico" significa che non ti aspetti che un 
record in modifica venga modificato anche da altri, nel qual caso la 
transazione viene annullata (a posteriori).
"Pessimistico" invece indica il blocco completo del record in fase di 
modifica (a priori), presumendo che sia probabile che piů utenti 
modifichino lo stesso record. E' un po' piů complesso da implementare 
per i rischio di deadlocks.
E' un vincolo a livello di database, anche se non tutti i motori db lo 
supportano e non tutti allo stesso modo.
Molto /in linea di massima/ ;-)

 Molto /in linea di massima/ ;-)
ok, cosa siano mi è chiaro
tu dici che è un vincolo a livello di database e qua forse non ci capiamo;
sono d'accordo che il motore db lo debba supportare ma l'unica volta che
ho utilizzato un pessimistic locking l'ho fatto attivandolo da codice
java, capito che intendo? e allora chiedo, è possibile anche attivarlo in
automatico sul DB (che lo supporta ovviamente) senza doverlo fare
esplicitamente da Java? e per l'optimistic come funziona?
spero di aver fatto chiarezza su quel che ho chiesto, grazie


 spero di aver fatto chiarezza su quel che ho chiesto, grazie
Sě, ma la risposta č: dipende :-)
Nel senso che i diversi database usano (quando possibile) metodi diversi.
Poi da java il locking in certi casi (es. postgres) si puň impostare via 
jdbc, senza bisogno di orm.
Quindi bisognerebbe innanzitutto capire che database usi e, 
indicativamente, cosa devi farci.

 indicativamente, cosa devi farci.
era una curiosità slegata da applicazioni pratiche almeno per ora
io ho pensato che ad esempio l'optimistic locking possa essere fatto solo
da Java, insomma gestito a livello di codice e non settato automaticamente
su DB mentre nel caso di p3ssimistic locking potrebbero esistere entrambi
le ipotesi (una l'ho già sperimentata da codice con Hibernate)
sono mie supposizioni


Forse ho capito :)
Ho come l'impressione che tu stia cercando, piů che il pessimistic 
locking in sč, informazioni sui livelli di isolamento delle transazioni, 
ecco il primo link che mi viene a tiro:
http://en.wikipedia.org/wiki/Isolation_(database_systems)
Il lock va comunque gestito tramite qualche comando, da java/sql/etc. 
appunto... perché poveretto il database non puň mica lockare in 
automatico ogni dato che leggi, altrimenti rimarrebbe bloccato in men 
che non si dica!
-- 
Dimitri De Franciscis
Phone:  
(+39) 3401570778
Website: 
http://www.megadix.it/

 che non si dica!
nel senso che sì ho fatto delle supposizioni poco pratiche


 che non si dica!
Perché, scusa?
Puoi tranquillamente impostare a pessimistic un db o anche solo una 
tabella: un utente legge un record, questo viene bloccato e se un altro 
utente cerca di accedervi o viene bloccato o può leggerlo in sola lettura.
Ovviamente vanno impostate anche regole di timeout del locking e 
verificare le relazioni tra tabelle per evitare deadlocks.
Unica cosa da fare lato applicativo, tanto per rimanere in tema, è 
avvisare l'utente che il record è bloccato (non accessibile o modificabile).
Usare un lock pessimistico comporta un'elaborazione più pesante ma è 
pratica perfettamente lecita e usata comunemente dove ci sono molti 
utenti che lavorano sugli stessi record.

 utenti che lavorano sugli stessi record.
aspettate, provo a scrivere qualcosa per chiarire
ammettiamo che stiamo usando un db che consenta entrambi i locking così ci
leviamo almeno questo problema
se vengono  gestiti da codice per me significa che nel codice Java (o PHP
o quel che vi pare) devo indicare qualcosa, tipo un'istruzione che dica
"su questo read/update usa il pessimistic locking" e nel caso di
optimistic qualcosa tipo "update record 1 set nome ='nuovonome' where id=1
and nome ='vecchionome'", insomma che sia sicuro di fare l'update prima
che il nome sia già stato cambiato (e se è già stato cambiato non eseguire
l'update)
gestiti da DB significa che tale codice (sia il primo che il secondo) non
deve essere specificato, se ne occupa il DB 
è chiaro? scusate ancora, grazie


 deve essere specificato, se ne occupa il DB 
Per quanto ho capito io leggendone proprio recentemente dal manuale,
l'optimistick locking si implementa via Hibernate impostando isolamento
read committed e versioning degli oggetti. In caso di aggiornamento da
transazione "parallela", Hibernate solleverà un'eccezione. In tutto ciò
il db non fa nulla se non per il tipo di isolamento scelto.
Per quanto riguarda il pessimistick locking, viene attivato via
Hibernate con qualcosa tipo session.lock (mi pare), ma di fatto chi lo
gestisce è il db, a cui viene inviato un comando come SELECT ... FOR
UPDATE che comunica la volontà di lockare il dato di interesse
-- 
Herbie