1

The question is in the context of Grails GORM programming, but it would be interesting to know the situation with this in other Hibernate uses, if there are indeed any real differences.

When one tries to save an object which was not selected with locking, one can get a StaleObjectStateException, if the database object was simultaneously updated by another thread/application. Hibernate docs say that after such an exception the whole session is unusable, because this exception may somehow mess up the session state. It seems that every object which was opened in this session also becomes unusable, even if such object was in fact not even modified by another thread. It seems that one cannot even .refresh()/modify/.save() the object in the same session either, even though logically that should work.

So what is the deal with the session breaking and is there a preferred way to deal with it? Re-selecting the object itself is not a problem, but the fact that every other object selected in that session becomes unusable is very problematic. I have a complicated method which loads a lot of these objects and keeps them in memory in different places, how do I go about handling this after an exception? I don't want to just rollback everything the method has done when one of the objects gets this exception, the logic is smart enough to just handle it, if there was a way to keep the session/objects operational. Does one really have to go through every single object in memory and somehow refresh it just because one of them was updated by another thread?

Is a StatelessSession something to consider?

Also maybe I am missing something here? There is a plethora of quesions about StaleObjectStateException, and almost none of them even list this as a concern? Isn't the fact that any object selected in the same session can randomly become unusable if just a single one of them was updated in the background a big goddamn inconvenience?

Cray
  • 2,396
  • 19
  • 29
  • you maybe want to see [this post](http://stackoverflow.com/questions/6097012/no-rollback-only-for-transaction-when-exception-occurs-in-submethod) – Angga Jul 22 '13 at 00:01
  • The documentation is clear. You must rollback the transaction and close the session when such an exception is thrown. There's no way around it. And i don't see how that is problematic. transactions should be extremely short in general. – JB Nizet Jul 22 '13 at 10:04
  • JB, it sounds like your comment assumes relationship "one transaction - one session". How does one make sure this is the case in Grails? Is this done automatically? Maybe that's the only way it is ever done and that's what I've been missing? But if one has to manually create new sessions for every transaction then I hope you can easily see why that is a problem... – Cray Jul 22 '13 at 17:53

0 Answers0