Hi guys,
I haven't been following this discussion too closely but I just wanted
to make sure we were on the same page in terms of the
specification. If, in an EJB implementation, I get the remote
interface through EntityContext or Session Context's
getEJBObject(), and I then proceed to make a call on that remote
interface before the current invocation returns, I am making a re-
entrant call that will always be illegal for a session bean, and be
illegal from an entity bean unless the entity is re-entrant. Does
everyone agree with this? (Some comments have seemed to imply
that it is not true.)
-Dan
On 8 Aug 00, at 21:52, Rickard �berg wrote:
> Hey
>
> 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".
> >
> > I ask you, are EJB calls from an instance reentrant calls?
>
> No. The spec idea is that EJB instances should not have to deal with
> reentrance. EJB-objects are not very interesting (and since they're
> mostly immutable thread reentrancy isn't very interesting)
>
> > IF yes or no, given our current architecture:
> > if yes then we have no option but specify the "isReentrant = true" if we
> > intend to use it...
> > if no then we need a way to detect "EJB calls" and let them be reentrant...
> > a pig really
>
> Detect EJB calls somehow is right.
>
> > My gut feeling is that the right option is "no" in the sense that an
> > instance should be able to do all the EJB stuff calls that it wants as part
> > of the flow of calls (if not the container will see them ALL wrong and they
> > are useless really)...
>
> Agree.
>
> > what I am saying is that saying "yes" means all EJB
> > callback calls will be seen as reentrant and stopped by default, :)
>
> Not necessarily, since it might be someone != the instance itself, that
> does the calling...
>
> > but the
> > fact that we see it on the same instance is specific to our implementation.
> > So for the sake of the callbacks being useful I suspect that EJB calls
> > cannot be seen as reentrant in our container even though they flow through
> > the container as such...
>
> Correct.
>
> > Note that this is a mix of two problems:
> > 1- One specific to us...the container reusing the same instance for
> > getEJBObject().getEJBHome().create() and hence locking
> > 2- One a bit "generic" which is "are callback objects reentrant"?
> >
> > The "solution" I put in there is "wrong", I know it but it is also ultra
> > trivial which is "reentrant calls are always ok" (and so I don't care if the
> > theory says reentrant or not), instead of significantly rethinking the
> > container at this point.
> >
> > 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..
>
> /Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
