Hey,
> 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.
what I'm doing right now is to check (among other things) if the
EnterpriseContext I want to passivate has a Transaction associated
if (ctx.getTransaction() != null)
If the above returns true, then I reinsert the bean in the cache. This bean
will then be passivated later, when one of the following happens:
a) it ages out of the cache because other beans of its kind are created /
used
b) expires for it the time for its active life 'cause it is too old
I think this is enough for CMT and BMT, am I correct ?
If the TX times out, I expect that its TX is nullified (am I right on this
in every case - BMT and CMT ?) and when a) or b) eventually happens it is
finally passivated.
Nevertheless, this introduce a new problem: the cache can pass its maximum
capacity.
Say I have cache max capacity 5; I create 5 beans and I leave all their
transactions active (so I cannot passivate them). Now I create a 6th bean...
cannot insert in cache, cannot free space in the cache... what now ?
I can set the max capacity to be virtually infinite (ie no max capacity),
and since the cache have a resizer that resizes its capacity we would have
no problem in *normal* use. Should I do this change in your opinion ?
Simon
>
> 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
> >
> >
> >
>
>
