Menu
With JPA, we can use manually OPTIMISTIC or PESSIMISTIC locking to handle entity changes in transactions.
I wonder how JPA handles locking if we don't specify one of these 2 modes ? No locking mode is used?
If we don't define an explicit locking mode, can the database integrity be lost?
Thanks
448
Hibernate optimistic locking only works in situation when you load object in one transaction, modify it and save it later in another transaction. In this case optimistic locking ensures that some other transaction haven't changed that object in the database in between.
To specify a lock on a custom query method of a Spring Data JPA repository, we can annotate the method with @Lock and specify the required lock mode type: @Lock(LockModeType. OPTIMISTIC_FORCE_INCREMENT) @Query("SELECT c FROM Customer c WHERE c.
In order to use optimistic locking, we need to have an entity including a property with @Version annotation. While using it, each transaction that reads data holds the value of the version property. Before the transaction wants to make an update, it checks the version property again.
Every JPA entity must have a primary key. You can specify a primary key as a single primitive, or JDK object type entity field (see "Configuring a JPA Entity Simple Primary Key Field").
I've scanned through section 3.4.4 Lock Modes of the Java Persistence API 2.0 Final Release specification and while I couldn't find anything specific (it doesn't state that this is the default or anything like that) there is a footnote which says the following.
The lock mode type NONE may be specified as a value of lock mode arguments and also provides a default value for annotations.
The section is about the kinds of LockModeType values available and their usages and describes which methods takes an argument of this kind and whatnot.
So, as it said LockModeType.NONE is default for annotations (JPA, annotations left and right) I guess when you use EntityManager.find(Class, Object) the default LockModeType is used.
There are some other, subtle, hints to reinforce this. Section 3.1.1 EntityManager interface.
The find method (provided it is invoked without a lock or invoked with LockModeType.NONE) and the getReference method are not required to be invoked within a transaction context.
It makes sense. For example if you use MySQL as your database and your database engine of choice is InnoDB then (by default) your tables will use REPEATABLE READ, if you use some other RDBMS or other database engines this could change.
Right now I'm not exactly sure that isolation levels has anything to do with JPA lock modes (although it seems that way), but my point is that different database systems differ so JPA can't decide for you (at least according to the specification) what lock mode to use by default, so it'll use LockModeType.NONE if you don't instruct it otherwise.
I've also found an article regarding isolation levels and lock modes, you might want to read it.
Oh, and to answer your last question.
If we don't define an explicit locking mode, can the database integrity be lost?
It depends, but if you have concurrent transactions then the answer is probably yes.
99
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
