Hi,
Suppose I have a server and multiple clients (running on different JVM and have their own Hibernate service) and all the clients have loaded the same data object tree to their JVM and are able to modify the data object tree anywhere/anyway they wish. The problem occurs at the data concurrency synchronisation, as a client persist the modifications made on the data object tree, the other clients need to synchronise the data object tree to keep the data consistent.
We have tried the refresh() method. It works perfectly except it is not a viable option if the object tree gets really large and complex. This is because the refresh() method reloads the whole object tree, therefore a lot of redundant database access and could potentially cause network congestion if the number of the clients require synchronisation become large.
So the approach we taken is to individually synchronise the attributes that
have been modified and each time the synchronisation occurs we also increase the version number (we have automatic versioning turned on for all of our objects). What we have found is that synchronising the version number attribute does not do the trick for us, as that is not what Hibernate use when it prepares the version validation SQL statemen. Therefore we still end up with the exception:
net.sf.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect)
My question is if anyone has come across this type of concurrency issue, and how do you deal with this problem? Could Hibernate be changed to use the version number attribue on the object for generating the version validation SQL statement?
Many thanks,
KC
|