Write to datastore generates no errors on incorrect @version attempt

Whilst using the JPA @Version is one method for implementing record locking it's not an ideal solution for the very reasons you've highlighted. If you want to lock records AND provide a meaningful User Experience then you'd be better of designing and implementing your own pessimistic record locking solution:

• create a table to hold locks (table will hold meta data about the entity and the instance that the lock is being held against, along with who took the lock and when)
• create a Stored Procedure that:
  • first checks if a lock is held against the entity in question. If one does then the Who/When are returned - you can then display these avlue sin the front end to the end-user
  • if there is no lock, then it takes a lock
  • when the processing is completed the lock is then removed from the locks table
  • whenever anyone wants to conduct some update processing against an entity then the process model first checks to see if the lock exists and either returns the who/when or returns a lock token

The beauty of this is that the End User can see that a lock exists AND who took it and WHEN.

S>

Whilst using the JPA @Version is one method for implementing record locking it's not an ideal solution for the very reasons you've highlighted. If you want to lock records AND provide a meaningful User Experience then you'd be better of designing and implementing your own pessimistic record locking solution:

• create a table to hold locks (table will hold meta data about the entity and the instance that the lock is being held against, along with who took the lock and when)
• create a Stored Procedure that:
  • first checks if a lock is held against the entity in question. If one does then the Who/When are returned - you can then display these avlue sin the front end to the end-user
  • if there is no lock, then it takes a lock
  • when the processing is completed the lock is then removed from the locks table
  • whenever anyone wants to conduct some update processing against an entity then the process model first checks to see if the lock exists and either returns the who/when or returns a lock token

The beauty of this is that the End User can see that a lock exists AND who took it and WHEN.

S>