[jboss-dev-forums] [Design of EJB 3.0] - Re: Issues with passivation of nested SFSBs

bstansberry@jboss.com do-not-reply at jboss.com
Mon Jan 29 13:32:53 EST 2007


"bill.burke at jboss.com" wrote : 
  | Nested SFSBs have to share the same lifecycle as their parents.  They also have to share the same Extended Persistence Contexts the reference!

OK, good; that's a clear rule that makes deciding how to handle everything else simpler. :)

This is broken if the nested SFSB declares @Remote. This test fails:


  | ParentStatefulRemote stateful = (ParentStatefulRemote) ctx.lookup("testParentStateful/remote");
  |       
  | assertEquals("Counter: ", 1, stateful.increment());
  |       
  | NestedStateful nested = stateful.getNested();
  |       
  | stateful.remove();
  |       
  | // Confirm nested no longer works following parent remove
  | try
  | {
  |    nested.increment();
  |    fail("Nested bean still exists following destruction of parent");
  | }
  | catch (Exception good)  
  | {
  |    // this is what we want -- nested has no independent lifecycle
  | }
  | 

I'll open a JIRA for this. Hopefully one of you guys can figure it out. I've been digging around trying to understand what's going on.  For some reason, if the nested bean declares @Remote, when a StatefulCache calls Pool.get(), it gets back a standard StatefulBeanContext rather ProxiedStatefulBeanContext.  This has to be a function of how calls are nested (i.e. the nested bean gets created *before* the parent, thus the parent hasn't been pushed onto the ThreadLocalStack when the nested bean is created.) 

As for the initial issue of the ProxiedStatefulBeanContext not being removed from the cache when it's parent is, I think I found that -- it was a bug in StatefulTreeCache.

anonymous wrote : Another thought I had was to actually store the Nested Bean's instance inide of its proxy and propagate it to the Nested Bean's EJB container via the invocation object.  If the invocation object had the actual bean instance already set, then the EJB container would not look in the cache.
  | 
  | I don't remember why I didn't do this....Maybe I didn't think of it at first?

Was this thought sparked by my last post re: replicating the proxy? That is, if we store the bean instance in the proxy and replicate it, that solves the issue?

If so, I think the reason you didn't do it that way was because you wanted the nested beans to always be serialized as a unit with the parent. Otherwise after deserialization you no longer have shared refs to things like ExtendedPersistenceContext.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007942#4007942

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007942



More information about the jboss-dev-forums mailing list