It is nothing you should try to shuffle under the carpet! It basically says that there are tow users (or processes) which try to update the same entity. This happens because of the use of optimistic-locking whith Entities with the @version (-ed) attribute. Not something to worry about unless it occurs too-much times a day, then you could use pestimistic locking. However this can have a nice impact on your performance.
You can catch the exception in pages.xml and do something (such as informaing the user).
<exception class="javax.persistence.OptimisticLockException"> <end-conversation before-redirect="true" /> <redirect view-id="yourViewWhereYouWantToGoAfterTheExceptionOccured.xhtml"> <message> Different users tried to update the same Incident </message> </redirect> </exception>
The main concern you should have, if this happens when the user has entered a lot of data in a form and after re-entering has to fill-in everything again...
Thank you a lot for your response :)
Under my pages.xml , I have done this:
<end-conversation before-redirect="true" />
<message>Another user changed the same data, please try again</message>
to catch my exception, but when seeing tomcat log's this exception still exist:
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.mycompany.seampoc.model.Employee#1]
The error still happens, you only have added Seam to do something with it.
So the qustion is: do you get the message and are you redirected ?
If it is not what you want (because there is just one user) look at the second part of the error which states that there could be something wrong with your maping.
(the entity Employee)
Yes i'm redirect to the editEmloyee.xhtml and the message appears
:-) when someone else change the same data :-), I think that the concurrency acces data work fine, but the error still happens!!
so my question is how can I avoid this exception
Tricky question, because there really is an error, so you should do something. If this happens a lot (meaning every minute) you should rethink your strategy for persistence . I presume its now optimistic locking and you have a number of users adding entities in collections of a specific Entity simultaneously. You could change to pesitmistic locking, but that can have a nice effect on performance.
I can't decide for you because I don't know the application and the requirements. I am working on a - still expanding - application which contains multiple access to the same entity by different users, and I have to deal with this and other comparable errors.
Personally I prefer to see an error and be sure that the user doesn't have to type in everything again. But that's a matter of taste.