Understanding jpa locks vs transaction isolation levels

Locking means, that you prevent entities from being updated by multiple users at the same time. There are two different types of lock mechanisms. In pessimistic locking scenarios, before performing an update, the rows in the table must be locked by the user and no other users will be able to perform an update of the target entities. After the row was updated, the table must be unlocked, so that other users can also modify the target records. Another option is using optimistic locking. In such implementations each entity has a version column (in JPA @Version can be used). If the entity was updated by a user, it's value or timestamp is also updated. If another user performs an update with a entity, that has an outdated value, an OptimisticLockException is thrown and the user or the application has to fetch the new entity and merge the changes. This functionality is needed to prevent entities from lost updates, where the last commit would override all other changes.

Transaction Isolation Levels are responsible for the consistency of database reads. For example if "READ UNCOMMITTED" is used, you can see changes, that a database is updating, before the transaction has already finished. That means, if an error occurred and the transaction was rolled back, another user would have fetched changes, that were never stored in the database. "READ COMMITTED" will deliver only committed changes.

There's no 'perfect' isolation level. The 'correct' value of the Transaction Isolation Level depends on the use case in your application. For example the JIRA Tempo Plugin for time tracking marks not committed records with a red color, to show that the data is pending.

Recommended topics

Hot tags