2 Replies Latest reply on Mar 20, 2009 7:14 AM by Raphael Pierron

    Back button, persistence context and conversation

    Raphael Pierron Newbie

      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.


      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.