"bill.burke(a)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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...