[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2209) Improve ways to transfer state information from a nested conversation to the parent conversation context

[Wolfgang Schwendt (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBSEAM-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12427546#action_12427546 ] 

Wolfgang Schwendt commented on JBSEAM-2209:
-------------------------------------------

Thanks again for your comment, Pete.   It's positive that default interceptors are now more configurable (JBSEAM-1485).  Given your comment that it's safe not to use the MEII in a non-clustered environment,   I searched through the Seam sourcecode whether the MEII was replaced by another tricky approach. I have found nothing, but maybe I've overlooked something new.   

Therefore, I tested what happens when a Seam-managed persistence context (SMPC) is used, an SFSB holds references to managed entities, and the MEII is disabled. After passivation and reactivation of the SFSB, the references held by the SFSB were pointing to detached rather than managed entities (exactly as expected without the MEII).   So my conclusion is that Gavin's statement made ~1 year ago ("ManagedEntityIdentityInterceptor is needed for any system which uses seam-managed persistence contexts) still holds true today even in a non-clustered environment.   

However, if the programmer knows what he's doing and understands the problem, it's possible to write code that is safe without the MEII.  For example, you can implement the app entirely without SFSBs,  use SFSBs with a container-managed extended PC rather than SMPC,  or alternatively merge back any detached entities to the SMPC when it's necessary to get managed entities again (eg. SFSB can implement a @PostActivate lifecycle method thats marks its conversational state as dirty, and on the next component method invocation the conversational state is explicitly merged back to the SMPC).   Alternatively as another approach, the effect of the MEII could be achieved if fields of an SFSB, which hold refs to managed entities, are annotated with @In @Out.  Then the disinjection by the BijectionInterceptor effectively clears these fields after any component method invocation, ensuring referential integrity after passivation/reactivation of the SFSB.

If I'm wrong or have overlooked something, please correct me.   It's an important question when apps are safe and when not (in a non-clustered app).  So I appreciate more comments about it.

> Improve ways to transfer state information from a nested conversation to the parent conversation context
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-2209
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-2209
>             Project: Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Wolfgang Schwendt
>            Priority: Critical
>         Attachments: nestedConversationsBehavior-Screenshots.pdf, nestedConversationsBehavior.zip
>
>
> When a nested conversation ends, it is difficult to transfer an ending result back to the parent conversation.    The following approach is currently not viable with Seam: We cannot simply access a component from the parent conversation and call a property Setter of this component with the ending result of the nested conversation supplied as argument for this Setter. The reason is that when a component from the parent conversation is called while the nested conversation is still in progress, the ManagedEntityIdentityInterceptor saves wrappers for the called component in the scope of the nested conversation (!) and not the scope of the parent conversation. So once the nested conversation scope gets destroyed at the end of the nested conversation, the saved wrappers for the component from the parent conversation get destroyed as well.
> Scenario:
> Suppose that we have a component AA in the conversation context with a field reference named 'bb' to an another component Q. At some point of time this reference is moved by the ManagedEntityIdentityInterceptor to a conversation-scoped context variable with the name "AA.bb".  Then we start a nested conversation. While the nested conversation is in progress, we can call a method of component AA and successfully access the field bb because at the time of the method invocation, the ManagedEntityIdentityInterceptor can retrieve the saved wrapper for field bb from the parent conversation context and put the contained reference into the component AA.  
> But then we call a method of component AA which changes the field bb.   At the end of this method invocation,  the ManagedEntityIdentityInterceptor moves the new value of reference field bb to a wrapper saved in the nested (!) conversation context.   Afterwards we end the nested conversation and the parent conversation resumes again.      When we then call a method of component AA again, the ManagedEntityIdentityInterceptor retrieves the wrapper for  field bb from the conversation context.  But this wrapper contains the old value for field bb, not the new value.    Note that the wrapper with the new value for field bb got destroyed already at the time when the nested conversation context was destroyed.
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118936&start=30
> Feature request regarding nested conversations
> Tue Sep 18, 2007 00:28 AM
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=121852
> Nested Conversations (tricky interceptor)
> Mon Oct 22, 2007 11:03 AM 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira