[jboss-user] [JBoss Seam] - Re: flushMode= MANUAL, when does commit happen? And other qu

AFAIK, you cannot perform multiple data entry conversations in a nested fashion without having an all-or-nothing problem with regards to saving the data. The problem is that each nested conversation uses the same persistence context, and when you flush for a nested conversation, you are flushing for all conversations using that persistence context (which includes all parent and child conversations). The conclusion I reached was that unfortunately, the nested conversation model was only good for browsing/navigating data due to the fact that it shares the persistence context. The Seam Issues example which was the only example to have editable pages in nested conversations was removed from the latest release (hope they re-write it to show how it should be done). Here are a couple of threads related to persistence contexts and nested conversations: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111681 http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111384 However, thinking about your problem more, you may be able to do something like : Start root conversation (with flushmode = automatic) Create mother entity Persist mother entity Set the entityManager flush mode to Manual At this point, you are in a manual flush mode, with the mother entity already created and persisted. If the child item also has child items, then you are in a sticky problem. Also this solution doesn't handle the problem of : Edit Mother Entity Add child Edit child Flush entity manager to save child -> Ooops, we just accidentally saved the changes to the mother also since the child is edited in a nested conversation, and we flushed the shared persistence context. Also, if your 'add child' or 'edit child' links could be opened in new windows, then you could have accidental flushes in each conversation when you just meant to save and flush one instance of the child editor. As for rolling back the mother entity in the event of a conversation timeout... If you have a flag called isNew which indicates whether it is a new entity or not, you can write a cancel changes procedure, something like: | String cancelChanges() { | if (isNew) { | em.remove(motherItem); | } else { | em.refresh(motherItem); | } | } | | I don't know the feasability of this, perhaps someone with more knowledge than me can comment, but you have a method marked with the @Destroy annotation, you could just call the cancel changes method from there if it has not already been saved (i.e. isNew is still true). This might be icky, but come to think of it, I'm wondering if this is a pretty handy pattern because what the conversation times out and you have made edits to the entity involved? Those edits could sit around in the persistence context after the conversation has timed out. Should the entity be refreshed because the persistence context might be re-used with the dirty object in it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063562#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...