[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2209) Fix passivation/activation of entities loaded using an SMPC
Pete Muir (JIRA)
jira-events at lists.jboss.org
Mon Nov 17 00:39:36 EST 2008
[ https://jira.jboss.org/jira/browse/JBSEAM-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12438586#action_12438586 ]
Pete Muir commented on JBSEAM-2209:
> To make a long story very short, you DO need to MEI if you are using SFSB w/ passivation enabled,
> even if you are not in a cluster. In the fact, the clustering is a separate and distinct concern of this
> interceptor that involves other parts of Seam as well.
Yes, this is not well documented.
> The issue at hand is that when the MEI is active, and a component from a parent conversation is
> invoked from the context of a nested conversation,
This is what the issue *was* about when Wolfgang originally filed, but I had expanded the issue to cover a number of other issues, but I wasn't clear about this I think.
> While I was messing around with the code, I also made the passivation smarter so that only collections
> and maps that actually contain entity references are preserved and not just any collection or map.
> This required iterating the collection or map until a reference is found. There is still room for optimization
> I'm sure.
Ok, you need to profile this, before and after as it sounds like this could add to the performance problems (although reduce memory footprint).
> Fix passivation/activation of entities loaded using an SMPC
> Key: JBSEAM-2209
> URL: https://jira.jboss.org/jira/browse/JBSEAM-2209
> Project: Seam
> Issue Type: Bug
> Components: Core
> Reporter: Wolfgang Schwendt
> Assignee: Dan Allen
> Priority: Blocker
> Fix For: 2.1.1.CR1
> 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.
> 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.
> Feature request regarding nested conversations
> Tue Sep 18, 2007 00:28 AM
> 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
More information about the seam-issues