Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best type for JPA version field for Optimistic locking

I have doubts about which is the best type for a field annotated with @Version for optimistic locking in JPA.

The API javadoc (http://docs.oracle.com/javaee/7/api/javax/persistence/Version.html) says:

"The following types are supported for version properties: int, Integer, short, Short, long, Long, java.sql.Timestamp."

In other page (http://en.wikibooks.org/wiki/Java_Persistence/Locking#Optimistic_Locking) says:

"JPA supports using an optimistic locking version field that gets updated on each update. The field can either be numeric or a timestamp value. A numeric value is recommended as a numeric value is more precise, portable, performant and easier to deal with than a timestamp."

"Timestamp locking is frequently used if the table already has a last updated timestamp column, and is also a convenient way to auto update a last updated column. The timestamp version value can be more useful than a numeric version, as it includes the relevant information on when the object was last updated."

The questions I have are:

  • Is better a Timestamp type if you are going to have a lastUpdated field or is better to have a numeric version field and the timestamp in other field?

  • Between numeric types (int, Integer, short, Short, long, Long) which is the best to choose (considering the length of each type)? I mean, I think the best is Long but it requires a lot of space for each row.

  • What happens when the version field gets to the last number of a numeric type (for example 32,767 in a Short field)? Will it start from 1 again in the next increment?

like image 240
Aliuk Avatar asked May 18 '14 14:05

Aliuk


People also ask

How do you implement optimistic locking in JPA?

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.

How do you handle optimistic lock exception?

To resolve this error we have two ways: Get the latest object from the database and set the old object values if you need those values to be persisted to the new object and merge it. For the old object set the latest version from Database.

How do you handle a pessimistic lock exception?

PessimisticLockException indicates that obtaining a lock or converting a shared to exclusive lock fails and results in a transaction-level rollback. LockTimeoutException indicates that obtaining a lock or converting a shared lock to exclusive times out and results in a statement-level rollback.


1 Answers

Just go with Long or Integer. BUT don't go with int or long. In opposite to other comment here, null value is expected when entity was never persisted yet. Having int or long might make Hibernate to think that entity is already persisted and in detached state as version value will be 0 when unset. Just finished debugging a FK violation where "int" was the cause, so save your time and just go with Long or Integer.

like image 72
Piotr Klimczak Avatar answered Dec 08 '22 03:12

Piotr Klimczak