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
