We have several wizards in the application we are developing under JBoss/icefaces/Spring.  We had decided some time ago to provide long running sessions to allow the user to move between wizard screens and then finalize (commit) later in time.

This all works pretty well until you get to a delete operation where there is some non-primary constraint involved.  The typical culprit is a unique ‘name’ for an object.  As you all know Hibernate takes all of the underlying SQL operations and lines them up in roughly the order of INSERT, UPDATE and then the DELETEs.  (There are a few other cases that do not apply here).

So, in a wizard if the user does something that boils down to add a thing called X, delete a thing called X and then add a thing called X again – your app will die.  Using the above Hibernate ordering you end up with INSERT X, INSERT X, and DELETE x throwing a constraint violation exception.

We have played with a few ideas here but none of them ‘feel’ like we are using Hibernate correctly:

• Don’t delete, just mark the record – doesn’t solve the unique constraint
• Cache deletes by hand – painful coding
• Delete forces a flush – violates the whole point of the long transaction/session

Leaning towards the last one now, but client may want #2.