2 Replies Latest reply on Jun 18, 2010 2:05 AM by Arbi Sookazian

    No more nested conversations in Seam 3?

    Arbi Sookazian Master

      I've heard that Seam 3.0 will most likely not feature nested conversations (also it's not included in JSR299).


      So what happens currently in Seam 2.x if you have a 5 page wizard with a conversation-scoped backing bean and on page 3 the user can begin a mini-usecase for adding a credit card to the checkout process for the outer usecase?  The mini-usecase is conversation-scoped as well (say it spans 3 pages) and joins the active LRC from the outer usecase.


      Ok, say you have one conversation-scoped SFSB for each usecase.  And you are injecting via @In EntityManager em; in both cases.  This means you're using SMPC which is conversation-scoped.  That means you're using the same extended PC for both conversation-scoped SFSBs.


      If you flush() in the 2nd SFSB for the credit card add usecase, then the SMPC is flushed for all changes to managed entities in both SFSBs b/c they share the same SMPC.


      This is obviously a problem and we don't want this to happen (i.e. if we flush() the mini-usecase, changes in the forms/screens from the outer usecase should not be saved).


      So what is the solution here?  Use two distinct SMPCs?  Doesn't that mean two EntityManagers tied to the same datasource?


      And how popular are usecases in real projects that involve nested usecases like this?


      Would it be possible to allow more than one active LRC at a time (or at least not be forced to use @Begin(join=true) and instead use @Begin(new=true) or simply @Begin and the Seam container would automatically set the original LRC to background and the new one as active?


      Currently IIRC the Seam container will throw an exception if it executes a method marked @Begin and a LRC is currently running/active...