"matt.drees" wrote : Hi Jacob, | | So you're not using a SMPC. I guess I tend to assume everybody uses them. :-) My bad. | | So I understand more, but I'm still missing a few pieces. | As for Jacob's approach, I think I roughly understand what he wants to achieve with his use of nested conversations, but so far I cannot completely follow either because some details of his approach are still unknown to us. "matt.drees" wrote : | "jacob.orshalick" wrote : ...Seam has taken a snapshot of my Person entity in the outer conversation on nesting (which didn't have the new addresses). The original Person instance will be reverted back to should the user back up to the original edit Person screen and submit. Seam retrieves the outer conversation by id on submit and restores the state of my Person object at the time of the snapshot which doesn't include the new addresses. | | | | It seems like you're embellishing Seam's behavior a little bit. It's my understanding that when you begin a nested conversation, Seam doesn't take a snapshot, it just creates a new empty "container", and prevents you from storing new objects in the parent container. While in the nested conversation, new objects are stored in this new container, and lookups look there before looking in the parent container; there's no automatic cloning going on. And if a user backbuttons out of a nested conversation, then there's no "restoring" going on, either; the nested container is simply not there, so new objects get stored in the parent container and lookups look there first. | | Exactly, I already thought the same yesterday evening. Jacob has repeatedly mentioned that Seam saves "snapshots", but I think that is not really the case. Seam manages contexts which are conceptually map-like data structures that associate context variable names (Strings) with object values. As regards contexts and nested conversations, when a new nested conversation is begun, Seam does in fact NOT clone the objects to which context variables from the parent conversation are bound. When a component class is annotated with @PerNestedConversation, however, any component instance of the same name that might exists in the parent conversation is invisible to its child conversations. This may lead to instantiation of a fresh component instance in the scope of a nested conversation when a @PerNestedConversationcomponent is being looked up. Do you make use of this @PerNestedConversationcomponent feature, Jacob? Alternatively, regarding Jacob's mentions of "saved snapshots", I was wondering whether perhaps he interprets the side-effects of the ManagedEntityIndentityInterceptor as "saving of snapshots". As described in my first post in this thread (#1), when a conversation-scoped component of the parent conversation is called from a nested conversation, the ManagedEntityIndentityInterceptor saves its wrappers for Entity fields or Entity collection fields in the scope of the nested conversation and not the parent conversation. It follows that once the nested conversation context is destroyed and the parent conversation resumes, these saved wrappers are gone, too (if I'm not mistaken). This may appear to be a reversion to a previous snapshot, but it is a reversion only as far as Entity fields or Entity collection fields are concerned. All other fields no wrappers are saved for by the ManagedEntityIndentityInterceptor are not reverted to old values. I'm not sure however whether Jacob's snapshot behavior is caused by the ManagedEntityIndentityInterceptor. If a Seam component is an Entity, no interceptor is added by Seam, thus no ManagedEntityIndentityInterceptor either. "matt.drees" wrote : | I'm guessing you must be doing this cloning manually somehow to get the behavior you describe, but you speak as if it's automatic. Could you explain a little more or show some code? | we need to know exactly how Jacob's does the management of Entity instances. How are they accessed, are context variables bound to them, and if so, with what scope? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086108#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...