Con JPA, è possibile utilizzare manualmente il blocco OPTIMISTIC o PESSIMISTIC per gestire le modifiche alle entità nelle transazioni.JPA e modalità di blocco predefinita
Mi chiedo come JPA gestisce il blocco se non si specifica una di queste 2 modalità? Non si usa la modalità di blocco?
Se non si definisce una modalità di blocco esplicita, l'integrità del database può essere persa?
Grazie
Ho esplorato attraverso la sezione 3.4.4 modalità di blocco della specifica Java Persistence API 2.0 Final Release e mentre io non ho trovato nulla specifica (ma non dice che questo è il default o qualcosa del genere) c'è una nota a piè di pagina che dice quanto segue.
Il tipo di blocco NESSUNO può essere specificato come un valore degli argomenti di blocco modalità e fornisce anche un valore predefinito per le annotazioni.
La sezione è sulle tipologie di LockModeType valori disponibili ei loro usi e descrive i metodi richiede un argomento di questo genere e quant'altro.
Quindi, come ha detto LockModeType.NONE è di default per le annotazioni (JPA, annotazioni a destra ea sinistra) credo che quando si utilizza il valore di default EntityManager.find(Class, Object)LockModeType viene utilizzato.
Ci sono altri sottili, suggerimenti per rinforzare questo. Sezione 3.1.1 Interfaccia EntityManager.
il metodo Find (a condizione che sia invocato senza una serratura o invocato con LockModeType.NONE) e il metodo getReference non sono tenuti ad essere invocato in un contesto di transazione.
Ha senso. Ad esempio se si utilizza MySQL come database e il motore di database scelto è InnoDB, quindi (per impostazione predefinita) le tabelle utilizzeranno lo REPEATABLE READ, se si utilizzano altri RDBMS o altri motori di database, ciò potrebbe cambiare.
In questo momento non sono esattamente sicuro che i livelli di isolamento abbiano nulla a che fare con le modalità di blocco JPA (anche se sembra così), ma il mio punto è che diversi sistemi di database differiscono in modo che JPA non possa decidere per voi (a almeno secondo le specifiche) quale modalità di blocco utilizzare per impostazione predefinita, quindi verrà utilizzato LockModeType.NONE se non diversamente specificato.
Ho anche trovato an article regarding isolation levels and lock modes, potresti leggerlo.
Oh, e per rispondere alla tua ultima domanda.
Se non si definisce una modalità di blocco esplicita, l'integrità del database può essere persa?
E dipende, ma se si dispone di transazioni concorrenti allora la risposta è probabilmente sì .
causa JPA 2.1 FR
3,2 Versione Attributi
Il campo Version o la proprietà viene utilizzata dal provider di persistenza per eseguire il blocco ottimistico. È accessibile e/o impostato dal provider di persistenza durante l'esecuzione delle operazioni del ciclo di vita sull'istanza dell'entità. Un'entità viene automaticamente abilitata per il blocco ottimistico se ha una proprietà o un campo mappato con un mapping della versione.
Quindi, se l'entità è un oggetto di versione, come ad esempio è stato specificato un @Version, poi il provider di persistenza di default eseguirà il blocco ottimistico.
Nella specifica persistence_2.0, pagina 89:
Se un oggetto di versione è altrimenti aggiornato o rimosso, quindi l'attuazione deve garantire che siano soddisfatti i requisiti di LockModeType.OPTIMISTIC_FORCE_INCREMENT, anche se non esplicito Chiamata a EntityManager.lock.
Modulo le risposte già presentati qui, sembra che APP si comporta nel modo seguente: Se la mia entità ha un campo annotato @Version un no LockModeType è stata impostata, quindi LockModeType.OPTIMISTIC_FORCE_INCREMENT verrà impostato di default. È corretto ?
Grazie per questa risposta costruttiva e il collegamento. Leggerò di nuovo e cercherò di capire LockModeType.NONE e cosa implica. Il fatto è che sono nuovo con JPA e non so esattamente quale entità (i) dovrei bloccare per mantenere l'integrità della certezza. Probabilmente è noioso, ma testerò tutte le modalità con la simulazione delle transazioni (Thread.sleep()). Grazie ancora –