Back button, persistence context and conversation

[rpie]

We are encountering an important technical problem with Seam. We are using Seam 2.1.
We are struggling with the fact that we share the same entitymanager in a conversation, even though we use the browser back button. We need best
practices advice, or workaround to solve this problem.

Example:

We have 2 pages, Page1.xhtml and Page2.xhtml.

Page1.page.xml describes that a long-running conversation should be started (in manual flush-mode), and some method executed to prepare data displayed by Page1.xhtml.

A “Next” button allows the user to go from Page1 to Page2 (the button propagates the conversation).

On Page2, the user can modify some entity properties and submit it while staying on the page; this submit is not a save, just set the properties on the entities. The user can also choose to save on this page, the save is flushing the persistence context.

Scenario :

1. The user goes to Page1, enter some information, and hit Next.

2. Page 2 is displayed.

3. The user enters some information and submit it – the user does not save.

4. The user presses the browser back button. Nothing changes on the server side at this point, i.e. the conversation is unchanged.

5. The user presses the Next button again.

6. Page2 is displayed.

7. The user presses save.

Problem : Between step 5 and 6, we would like to get rid of all the changes made by the user on the entities before the back button was pressed; i.e. we would like our entities to be in the same state in step 6 as in step 2.

Today, this is not the case, the changes done in step 3 are kept and returned by the entity manager until the end of the conversation. The data
is always retrieved using the Seam-managed entity manager, what we would like is clear the persistence manager cached data and start from fresh
without killing the conversation (we still want to rely on the conversation for passing data between Page1 and Page2).
We thought about using a nested conversation, but nested conversations shares the same entityManager as their parent conversation, therefore it does not help us.

[monkeyden]

If you're using manual flush-mode manual then you simply have a dirty object (by way of value binding).  You'll have to refresh it.

[rpie]

Yes, but refreshing each dirty entity sounds expensive, in terms of performance and development effort (we would have to keep track of the potentially modified entities); I forgot to say that Page2 is complex and maps fields to hundreds of entities, some of them even being transient entities that we don't want to persist at save time.
I finally think the way to go for us is to do a entitymanager.clear() and then merge the Page1 entities used in Page2..