[EJB3 -JPA] lock pessimistico,ottimistico...how to?

[javacomelava]

Salve

Essendo alle prime armi con queste tecnologie mi sono trovato,nello sviluppo di un'applicazione web,ad avere a che fare con i lock.

Da quello che ho trovato in giro non sono riuscuto a capire se c'e' un meccanismo di default per la gestione della concorrenza con ejb e jpa oppure è compito del programmatore dover definire i lock a livello di entità.

Qualcuno che ne sà qualcosa in piu che riesce a darmi una delucidazione a riguardo?

saluti

[nuovoUtente86]

In linea generale le transazioni vengono gestite dal Container (che se si può operare in maniera programmatica).
Se ti interessa l' utilizzo di un lock ottimistico esiste l' annotation @Version, atta proprio allo scopo.

[javacomelava]

Ciao,grazie per la risposta.

Quindi se sto usando EJB3 con CMT (Container managed transaction)dovrebbe essere compito del container occuparsi del locking.

Quello che mi domando allora è:

Se il programmatore lascia fare al container,come si comporta questo in caso di transazioni concorrenti(soprattutto in scrittura)???
Attua un lock ottimistico? pessimistico? In caso di lock questo come viene gestito dal container(lancia un'eccezione...?!?!? )???

Intanto do un'occhiata all'annotazione @Version che mi hai suggerito!

[nuovoUtente86]

Di norma il grado di isolmanto utilizzato dipende dal database utilizzato ed è quindi trasparente ai client ejb.
Il lock ottimistico trova utilizzo in quelle condizioni, dove nonostante ci sia un alto numero di transazioni, si ritiene che diffcilmente interverrano problemi di concorrenza.
Provo a farti un esempio pratico: ipotizziamo che un entity corrisponda ad una inserzione ebay, avremmo di norma 3 tipologie di client busness interessati alla rappresentazione , mediante oggetto, dell' inserzione stessa:
-i visitatori/acquirenti
-l' inserzionista
-i dipendenti ebay.
Ipotizziamo che i primi possano solo consultare (per le offerte un lock ottimistico sarebbe un po azzardato)mentre gli altri 2 anche modificare, bene non avrebbe senso, fino alla modifica, andare a pescare sempre dal serbatoio persistente, ma possiamo utilizzare una copia locale, allorquando un inserzionista o l' amministratore facciano delle modifiche, il sistema di lock ottimistico dovrà confrontare che la versione presente sul DB sia quella effettivamente letta e quindi non modificata da nessun altro, altrimenti si lancia un' eccezione.