Hi Val, Yes, I think it's reasonable to handle "update_timestamp" before it goes into Ignite cache instead.
As for "locking" however, we are relying on Hibernate's support for optimistic locking - https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html Basically when Hibernate saves an object, it will increment an integer on it. For example, if you have 2 people trying to update an object at the same time: Person A reads myObj (locking = 0) Person B reads myObj (locking = 0) Person A updates and commits myObj (Hibernate verifies locking = 0, and then increments it to 1) Person B updates and commits myObj (Hibernate verifies locking = 1, it's not, so this update is rolled back) -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/CacheStore-implementation-using-Hibernate-tp1423p1452.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
