Hello,
> marc fleury wrote:
> > If a target bean does a getEJBObject.getEJBHome(), at least
> today he gets
> > something (...) but if he goes on calling something with it
> (create() in the
> > example above) then the current architecture and
> implementation are such
> > that the call ends up on the same instance. It's f*cked up
> but that is the
> > way it is.
> >
> > Then of course, the container "locks" saying that this is a
> "reentrant
> > call".
> >
tough stuff, but I managed to understand the problem generated by the
getEJBObject call :-P
> we need a way to detect "EJB calls" and let them
> be reentrant...
> > a pig really
>
> Detect EJB calls somehow is right.
There can be a way in the actual implementation, but I need confirms: the
client can retrieve the EJBObject only through the
EntityContext.getEJBObject ? If so, then all the client requests for the
EJBObject pass through
EntityEnterpriseContext.EntityContextImpl.getEJBObject and there we can set
a flag that we can test in the EntityInstanceCache to see if the call is an
"EJB call" or not.
> > The final thing I argue in there is that more people will
> be concerned with
> > calls on getEJBObject().anEJBcall() not working properly
> (all the callbacks
> > to the container) before they actually throw a tantrum
> about the "reentrant"
> > thingy. <Grin>
> >
> > So it's your call really but there are more pressing stuff
> that "designing
> > the container for this exception". Let's not design by
> exception is my one
> > true philosophy.
>
> Agree, but how to solve cleanly? One way could be to make an
> interceptor
> that sits above the InstanceInterceptor.. ah shit... we still need the
> instance for ejbRemove though.. not sure if the instance
> itself can call
> ejbRemove though.. humdidum.. tricky..
>
Marc, after your last answers to Rickard and me, I've understood that since
isReentrant returns true by default I shouldn't check for the reentrant
problem in rewriting the EntityInstanceCache. But your intention to split
cache acquisition and cache synchronization means that I should really know
what will be competence of the EntityInstanceCache and what is not, so I'll
wait for further details.
Anyway, thanks for the great in-depth sight of jBoss, the more I understand
of it, the more I like it :-)
Simon