StatefulBeanContext already has a "removed" field, and already has a ref to all its (non @Remote) children. Those children already have a ref to the parent. So it should be quite easy to just change the caching code to not de-cache the parent while any children are alive. Then StatefulInstanceInterceptor just checks the removed field to ensure the parent is no longer accessible (should probably do that anyway). That seems easier than moving data around from one bean to another. It's a quick and dirty improvement, if such a thing is wanted for RC10/4.2. But, a general problem with making XPCs and managed entities part of the replicated state of any SFSB is the possibility of something like this: 1) Parent A has nested children B and C. 2) A exposes getters for B and C, and 3 separate clients have refs to A, B and C. 3) All 3 clients make concurrent requests that result in a need to replicate. This can result in one thread attempting to serialize the bean instances, calls to @PrePassivate, etc. while another thread is actively operating on the bean. Yuck! Encapsulating the shared state in something like an XPCHolder might help with that, if the XPCHolder could be cached and replicated independently of the bean instances. This assumes that one thread serializing the XPC and managed entities while another thread is using them is not a problem. A separate caching infrastructure for XPCHolder would take quite a bit of time, as I'm sure there are hidden gotchas. Another potential workaround to the concurrent replication problem is to modify StatefulInstanceInterceptor to require a lock on the parent bean before an invocation can proceed. Serialize the requests to A, B, C. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008849#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...