|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bordet, Simone
|Sent: Tuesday, October 10, 2000 2:28 AM
|To: 'jBoss Developer'
|Subject: RE: [jBoss-Dev] Passivating caches and lock on CMT tx
|
|
|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
good, please commit that code ASAP
|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 guess I don't see why a reinserted bean needs to behave any differently
than "normal" beans. I did code an "update usage" just like when a bean is
called so that it goes back as a "currently in use" bean and goes out of the
"LRU" scope... is your implementation LRU?
|I think this is enough for CMT and BMT, am I correct ?
Yes
|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.
Make sure tha the passivation does behave properly, we seem to have problems
with the timeout in the container right now...
BTW, I will send another mail with this but I came back this morning and
sebastien showed me his latest fixes (Ole there were some leaks in the Tx
stuff still, let's make sure this is fool -proof) and the numbers are
terrific: it goes up to 150000 beans and 200 threads in parallel with a heap
of 6MB !!!!!! (YES!!!:))))))
|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 ?
good point, I guess the "max size" algorythms have this problem... (Random
passivation right?). Again the LRU passivation works fine with this (as I
update the usage if there is a transaction). One thing I would do it work
from the current size of the cache and only 'sweep' once in this fashion you
won't loop but the map will grow accordingly. At every iteration you will
try to passivate but you will reach the end.
marc
|
|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
|> >
|> >
|> >
|>
|>
|
|
