So, what the hell happens when you try and save changes to an @Version’d entity when another thread saves it’s changes before you?

Imagine you’re setup with a JPA 2 environment, using Spring Data JPA and Hibernate is your JPA vendor. You have a UserRepository interface which extends JpaRepository and therefore a Spring generated userRepository bean for all your user DAO needs. You also have a User domain object with a field annotated with @Version.

FYI, your find, save, delete etc. methods in your userRepository are automatically @Transactional. Thank you, Spring.

Ok, lets formalise this a bit:

Thread 1 finds User record with ID 1
Thread 2 finds User record with ID 1
Thread 2 changes the email address field
Thread 2 saves the changes to their version of the user object
Thread 1 changes the email address field
Thread 1 saves the changes to their version of the user object

At the point where thread 1 saves changes, it’ll check the version field of the user object and also the version of the user object in the database. They’ll be different, and a HibernateOptimisticLockingFailureException will be thrown.

Note also that the exact same thing happens if either thread 1 or thread 2 had deleted the object. So, all well and good huh? Check this out for sensible:

Thread 1 finds User record with ID 1
Thread 2 finds User record with ID 1
Thread 2 changes the email address field
Thread 2 saves the changes to their version of the user object
Thread 1 changes nothing, but then saves their version of the user object

What happens here? I originally thought thread 1 would throw an optimistic locking exception. Except, it doesn’t – Spring/JPA/whoever is in charge back there is smart enough to know that nothing changed, so it doesn’t save anything, and you end up with thread 2′s changes as you wanted. Clever girl.