Hibernate version: 1.0.2.0

Hello folks,

I've come across a behavior I didn't unexpected and I wonder if it's a bug - my version number on the stale object remains incremented after the rollback triggered by the StaleObjectException.

here's the sequence (in a web-app):
-first post
a1. load the object and place it in the viewstate

-second post
b1. in another window load 2nd copy

-3rd post
c1. update the object from UI
c2. open transaction
c3. try to saveOrUpdate
c4. commit
- it's all nice and saved, and the version in db and the 1st copy incremented

-4th post
d1. update the 2nd copy from UI
d2. open transaction
d3. try to saveOrUpdate (the 2nd copy)
d4. catch and rollback
- at this point the database is intact, but the 2nd copy's version is updated (and incidentally matches the version in DB)

The version mapping:


It doesn't seem... natural. And the real problem is, the 2nd copy (with now updated version) is automaticaly serialized back into the viewstate and subsequent attempt at save succedes when it shouldn't!

Any thoughts?

TIA,
ET

well _technically_ speaking, you aren't handling your exception properly. there are some other threads on this board that discuss the behavior you are referencing and they contain some comments from sergey. beyond that, when you catch your exception, you are supposed to abandon all changes to your object or otherwise handle the exception you are catching, besides simply displaying an error message in the UI. here are some ideas:

1) use the Memento Pattern to "undo" to when you get the StaleObjectException thereby placing the original object back into the ViewState (altough I don't really see the value of this and have never used it).

2) build business logic into the exception handler that allows the user to compare the two states of an object and reconcile.

3) session.Load(), session.Update(), or session.Lock() the object to automatically reconcile the object with the persistent state depending on what you want to do. obviously session.Load() will abandon all changes from second post, session.Update() will persist those changes without asking (ouch!), and session.Lock() can do a number of things including updating the in-memory state of the entity with the db.

obviously these three options are greatly affected by the needs of your application, but, basically you need to figure out a way to prevent that object from showing up in your ViewState.

Appreciate the comments, but I don't believe the matter of exception handling is the issue here.



The session is in undetermined state after the rolled back transaction and supposed to be abandoned. I have no problem with that. But my business object better be intact, otherwise persistence layer concerns are leaking into the higher levels, where they don't belong.
To illustrate the point, consider a framework where transactions are independent from persistence (say Spring), and it's the commit (which knows nothing about the objects being saved) fails.

Funny enough, version attribute of another complex class following similar scenario stays the same!