Quick addendum: change "session bean" to "stateful session
bean."
-Dan
On 9 Aug 00, at 12:25, "jBoss Developer" <[EMAIL PROTECTED] wrote:
> 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
> >
>
>
