I think I have finally sorted this out. This seems to be due to my use of the following in my editor's "apply" method: | ... | Conversation.instance().end(); | Conversation.instance().pop(); | | // We are in the parent conversation now ... | serviceMgmt.refresh(); | | serviceEndPointMgmt.refresh(); // This is the bug | | ... | I used this instead of the normal @End as I wanted to update the serviceMgmt in the parent's conversation to reflect the edit. Since componet serviceMgmt is "read-only" in the nested conversation, I have to get back to the parent to update it. The reference to serviceEndPointMgmt must have caused a re-instantiation of this component, in the parent conversation, since I am using @In(create=true) This reference is just a bug; it was completely unnecessary. This is how the parent conversation obtained a reference to the ID of a cached serviceEndPointMgmt object. It also explains what I saw in the logs. Since the parent's conversation's beans don't touch serviceEndPointMgmt, it timed out of the cache. The next edit session (a new nested conversation) inherited the reference from the parent, tried to get the bean from the cache and caused the stateful bean error. Once I removed the reference, my application behaved properly. It looks like Peter was right about the root cause of this.... Can anyone confirm/deny this explanation? Hopefully this will help someone, somewhere... PdP View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070828#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...