OK,
I am on top of this one (as answered in the private mails)
here is the skinny...
right now some "reentrancy" is done in the cache. The call looses the
"invoke" "invokeHome" trail since the cache is not aware of it. However the
cache takes the decision.
The right way is to rewire the decision in the InstanceInterceptor (no need
for a new interceptor actually, my bad) and I tried to do that.
There is one lingering issue and that is that the "lock" information is
cache proprietary at this point. It would just take refactoring to expose
it to the II so that he can do essentially the same code that the cache is
doing but in the invoke and invokeHome trails so that the right decision can
be taken.
No biggy, but also NOT a priority "today". Maybe tomorrow but it is
refactoring
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bordet, Simone
> Sent: Friday, August 11, 2000 3:37 AM
> To: jBoss Development Mailing List (E-mail)
> Subject: [jBoss-Dev] Stateful Instance Cache
>
>
> Hello,
>
> I run in the same EJBObject calls problem (for the stateful
> instance cache I
> wrote) found for the entity instance cache.
> Since the best solution, as I've understood from previous posts, is to add
> an interceptor, I'll try to figure out one for the stateful cache.
> Marc, Rickard, others, any thoughts ?
>
> Simon
>
>
