<here comes the old timer/>
the locking logic with passivation is trickier, cf jboss1.0 where most of it
was in place but not leak proof.
The Tx should be checked and not passivated if present. I don't even think
that BMT is ok since the timeout would apply to these and we need to call
back somehow.
If I remember correctly I really got headaches to check for "in passivation"
and "in activation" where the beans are not yet in the standard maps but "in
transition"... tricky, make sure that is done
amrc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> Sent: Sunday, October 08, 2000 1:56 AM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] Passivating caches and lock on CMT tx
>
>
> Hi!
>
> "Bordet, Simone" wrote:
> > the caches (stateful and entity) run fine, jbosstest passes
> cleanly. There
> > is still an open issue:
> > in CMT TX managed beans (both stateful and entity) there is the
> possibility
> > that after the instance int'r unlocks the context and that
> *before* the tx
> > int'r lock it again in the Synchronization implementation, the
> passivation
> > for it occurs.
> > It can be solved by adding another flag in EnterpriseContext
> that tells that
> > a Synchronization has been registered (and thus will be called
> later) and
> > delay the passivation if this flag returns true (I already do a similar
> > check with EnterpriseContext.lock()), but maybe you've better ideas.
>
> I would recommend checking if the instance has a tx associated with it
> or not. Don't passivate if it has a tx (at least not for EntityBeans,
> stateful sessions with BMT may be ok since the tx's are long-lived).
>
> /Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
>
>
