Blocco pessimistico nell'APP

1. Panoramica

Ci sono molte situazioni in cui vogliamo recuperare i dati da un database. A volte vogliamo bloccarlo per noi stessi per ulteriori elaborazioni in modo che nessun altro possa interrompere le nostre azioni.

Possiamo pensare a due meccanismi di controllo della concorrenza che ci consentono di farlo: impostare il livello di isolamento della transazione appropriato o impostare un blocco sui dati di cui abbiamo bisogno al momento.

L'isolamento delle transazioni è definito per le connessioni al database. Possiamo configurarlo per mantenere il diverso grado di dati di blocco.

Tuttavia, il livello di isolamento viene impostato una volta creata la connessione e influisce su ogni istruzione all'interno di quella connessione. Fortunatamente, possiamo utilizzare il blocco pessimistico che utilizza meccanismi di database per riservare un accesso esclusivo più granulare ai dati.

Possiamo utilizzare un blocco pessimistico per garantire che nessun'altra transazione possa modificare o eliminare i dati riservati.

Esistono due tipi di serrature che possiamo mantenere: una serratura esclusiva e una serratura condivisa. Potremmo leggere ma non scrivere nei dati quando qualcun altro possiede un blocco condiviso. Per modificare o eliminare i dati riservati, è necessario disporre di un blocco esclusivo.

Possiamo acquisire blocchi esclusivi utilizzando le istruzioni " SELECT ... FOR UPDATE ".

2. Modalità di blocco

La specifica JPA definisce tre modalità di blocco pessimistiche di cui parleremo:

  • PESSIMISTIC_READ - ci permette di ottenere un blocco condiviso e impedire che i dati vengano aggiornati o cancellati
  • PESSIMISTIC_WRITE - ci permette di ottenere un blocco esclusivo e impedire che i dati vengano letti, aggiornati o cancellati
  • PESSIMISTIC_FORCE_INCREMENT - funziona come PESSIMISTIC_WRITE e incrementa inoltre un attributo di versione di un'entità con versione

Sono tutti membri statici della classe LockModeType e consentono alle transazioni di ottenere un blocco del database. Vengono tutti conservati fino al commit o al rollback della transazione.

Vale la pena notare che possiamo ottenere solo un lucchetto alla volta. Se è impossibile, viene generata un'eccezione PersistenceException .

2.1. PESSIMISTIC_READ

Ogni volta che vogliamo solo leggere i dati e non incontrare letture sporche, potremmo usare PESSIMISTIC_READ (blocco condiviso). Tuttavia, non saremo in grado di effettuare aggiornamenti o eliminazioni.

A volte capita che il database che utilizziamo non supporti il blocco PESSIMISTIC_READ , quindi è possibile che otteniamo invece il blocco PESSIMISTIC_WRITE .

2.2. PESSIMISTIC_WRITE

Qualsiasi transazione che deve acquisire un blocco sui dati e apportare modifiche dovrebbe ottenere il blocco PESSIMISTIC_WRITE . Secondo la specifica JPA , tenere premuto il blocco PESSIMISTIC_WRITE impedirà ad altre transazioni di leggere, aggiornare o eliminare i dati.

Si noti che alcuni sistemi di database implementano il controllo della concorrenza multi-versione che consente ai lettori di recuperare i dati che sono già stati bloccati.

2.3. PESSIMISTIC_FORCE_INCREMENT

Questo blocco funziona in modo simile a PESSIMISTIC_WRITE , ma è stato introdotto per cooperare con entità con versione, entità che hanno un attributo annotato con @Version .

Qualsiasi aggiornamento delle entità con versione potrebbe essere preceduto dall'ottenimento del blocco PESSIMISTIC_FORCE_INCREMENT . L'acquisizione di tale blocco comporta l'aggiornamento della colonna della versione.

Spetta a un provider di persistenza determinare se supporta PESSIMISTIC_FORCE_INCREMENT per entità senza versione o meno. In caso contrario, genera PersistanceException .

2.4. Eccezioni

È utile sapere quale eccezione può verificarsi mentre si lavora con il blocco pessimistico. La specifica JPA fornisce diversi tipi di eccezioni:

  • PessimisticLockException : indica che l'ottenimento di un blocco o la conversione di un blocco condiviso in un blocco esclusivo non riesce e si traduce in un rollback a livello di transazione
  • LockTimeoutException: indica che l'ottenimento di un blocco o la conversione di un blocco condiviso in un blocco esclusivo è scaduto e si verifica un rollback a livello di istruzione
  • PersistanceException: indica che si è verificato un problema di persistenza. PersistanceException e i relativi sottotipi, ad eccezione di NoResultException , NonUniqueResultException, LockTimeoutException e QueryTimeoutException, contrassegnano la transazione attiva di cui eseguire il rollback.

3. Utilizzo di serrature pessimistiche

Esistono alcuni modi possibili per configurare un blocco pessimistico su un singolo record o gruppo di record. Vediamo come farlo in JPA.

3.1. Trova

Probabilmente è il modo più semplice. È sufficiente passare un oggetto LockModeType come parametro al metodo find :

entityManager.find(Student.class, studentId, LockModeType.PESSIMISTIC_READ);

3.2. Query

Inoltre, possiamo usare anche un oggetto Query e chiamare il setter setLockMode con una modalità di blocco come parametro:

Query query = entityManager.createQuery("from Student where studentId = :studentId"); query.setParameter("studentId", studentId); query.setLockMode(LockModeType.PESSIMISTIC_WRITE); query.getResultList()

3.3. Blocco esplicito

È anche possibile bloccare manualmente i risultati recuperati dal metodo find:

Student resultStudent = entityManager.find(Student.class, studentId); entityManager.lock(resultStudent, LockModeType.PESSIMISTIC_WRITE);

3.4. ricaricare

Se vogliamo sovrascrivere lo stato dell'entità con il metodo refresh , possiamo anche impostare un blocco:

Student resultStudent = entityManager.find(Student.class, studentId); entityManager.refresh(resultStudent, LockModeType.PESSIMISTIC_FORCE_INCREMENT);

3.5. NamedQuery

L' annotazione @NamedQuery ci consente di impostare anche una modalità di blocco:

@NamedQuery(name="lockStudent", query="SELECT s FROM Student s WHERE s.id LIKE :studentId", lockMode = PESSIMISTIC_READ)

4. Blocco dell'ambito

Il parametro Lock scope definisce come gestire le relazioni di blocco dell'entità bloccata. È possibile ottenere un blocco solo su una singola entità definita in una query o bloccarne ulteriormente le relazioni.

To configure the scope we can use PessimisticLockScope enum. It contains two values: NORMAL and EXTENDED.

We can set the scope by passing a parameter ‘javax.persistance.lock.scope‘ with PessimisticLockScope value as an argument to the proper method of EntityManager, Query, TypedQuery or NamedQuery:

Map properties = new HashMap(); map.put("javax.persistence.lock.scope", PessimisticLockScope.EXTENDED); entityManager.find( Student.class, 1L, LockModeType.PESSIMISTIC_WRITE, properties); 

4.1. PessimisticLockScope.NORMAL

We should know that the PessimisticLockScope.NORMAL is the default scope. With this locking scope, we lock the entity itself. When used with joined inheritance it also locks the ancestors.

Let's look at the sample code with two entities:

@Entity @Inheritance(strategy = InheritanceType.JOINED) public class Person { @Id private Long id; private String name; private String lastName; // getters and setters } @Entity public class Employee extends Person { private BigDecimal salary; // getters and setters }

When we want to obtain a lock on the Employee, we can observe the SQL query which spans over those two entities:

SELECT t0.ID, t0.DTYPE, t0.LASTNAME, t0.NAME, t1.ID, t1.SALARY FROM PERSON t0, EMPLOYEE t1 WHERE ((t0.ID = ?) AND ((t1.ID = t0.ID) AND (t0.DTYPE = ?))) FOR UPDATE

4.2. PessimisticLockScope.EXTENDED

The EXTENDED scope covers the same functionality as NORMAL. In addition, it's able to block related entities in a join table.

Simply put, it works with entities annotated with @ElementCollection or @OneToOne, @OneToMany etc. with @JoinTable.

Let's look at the sample code with the @ElementCollection annotation:

@Entity public class Customer { @Id private Long customerId; private String name; private String lastName; @ElementCollection @CollectionTable(name = "customer_address") private List addressList; // getters and setters } @Embeddable public class Address { private String country; private String city; // getters and setters }

Let's analyze some queries when searching for the Customer entity:

SELECT CUSTOMERID, LASTNAME, NAME FROM CUSTOMER WHERE (CUSTOMERID = ?) FOR UPDATE SELECT CITY, COUNTRY, Customer_CUSTOMERID FROM customer_address WHERE (Customer_CUSTOMERID = ?) FOR UPDATE

We can see that there are two ‘FOR UPDATE‘ queries which lock a row in the customer table as well as a row in the join table.

Another interesting fact we should be aware of is that not all persistence providers support lock scopes.

5. Setting Lock Timeout

Besides setting lock scopes, we can adjust another lock parameter – timeout. The timeout value is the number of milliseconds that we want to wait for obtaining a lock until the LockTimeoutException occurs.

We can change the value of timeout similarly to lock scopes, by using property ‘javax.persistence.lock.timeout' with the proper number of milliseconds.

It's also possible to specify ‘no wait' locking by changing timeout value to zero. However, we should keep in mind that there are database drivers which don't support setting a timeout value this way.

Map properties = new HashMap(); map.put("javax.persistence.lock.timeout", 1000L); entityManager.find( Student.class, 1L, LockModeType.PESSIMISTIC_READ, properties);

6. Conclusion

When setting the proper isolation level is not enough to cope with concurrent transactions, JPA gives us pessimistic locking. It enables us to isolate and orchestrate different transactions so they don't access the same resource at the same time.

To achieve that we can choose between discussed types of locks and consequently modify such parameters as their scopes or timeouts.

D'altra parte, dovremmo ricordare che la comprensione dei blocchi del database è importante quanto la comprensione dei meccanismi dei sistemi di database sottostanti. È anche importante tenere presente che il comportamento dei blocchi pessimistici dipende dal provider di persistenza con cui lavoriamo.

Infine, il codice sorgente di questo tutorial è disponibile su GitHub per l'ibernazione e per EclipseLink.