> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bordet, Simone
> Sent: Tuesday, August 08, 2000 6:54 AM
> To: jBoss Development Mailing List (E-mail)
> Subject: [jBoss-Dev] Entity Instance Cache
>
>
> Hello,
>
> I'm rewriting the instance cache for entity beans, and in
> NoPassivationEntityInstanceCache I see a remark done few days ago
> that will
> avoid throwing a RemoteException when a reentrant call is made and isn't
> allowed.
> Marc, can you explain me in more detail what happened and why you remarked
> it ?
hey,
This is one is a bit of a pig. Follow the TestBeans.jar
CMPEntity.createEntity() call.
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?
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
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)... what I am saying is that saying "yes" means all EJB
callback calls will be seen as reentrant and stopped by default, :) 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...
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.
>
> Code follows:
>
> // MF FIXME
> // This is wrong but doing it right requires time
> // The problem is that the entity EJB calls from an instance
> // come back on the instance and in the presence of a
> // transaction it throws the exception....
> // Since I suspect most people will use the EJBObject method calls before
> they set the reentrant right :)
> // I would rather bypass the default for now.
> //throw new RemoteException("Reentrant call not allowed");
>
> I will try to fix this doing it right, but I don't follow you in the
> comments.
I appreciate it, but I wouldn't worry for now (or do so, your call). I can
tell you where help is needed though:)
marc
>
> Thanks
>
> Simon
>
>
