No more nested conversations in Seam 3?

[asookazian]

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...

[nickarls]

Not that I've actually tried it but in Weld both Conversation and ConversationManager are injectables so if you have a clear picture on how to do stuff, go alternative.

[asookazian]

what do you mean exactly by go alternative?

How bout adding addConversation method to the ConversationManager API?

When you have an embedded LRC (mini-usecase within the usecase) then you're in effect adding a conversation.  Or I guess suspending the active LRC for the LRC associated with the mini-usecase.  Which seems to be similar to the nesting concept from Seam 1/2.

But then there's the issue of how to handle the SMPC with nesting.

Hmmm....