> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Bordet, Simone
> Sent: Tuesday, July 03, 2001 4:06 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
> incomplete.
>
>
> > I wasn't saying that you shouldn't protect the cache or the
> > context, but for
> > cache.release(ctx), again, why schedule the passivation? Why not just
> > passivate it.
> >
> > public void release(ctx)
> > {
> > synchronized(getCacheLock())
> > {
> > Object id = getKey(ctx);
> > if (canPassivate(ctx))
> > {
> > if (getCache().peek(id) != null)
> > {
> > getCache.remove(id);
> > }
> > passivate(ctx);
> > }
> > }
> > }
> >
> > The above code protects the cache, but doesn't add the complication of
> > another thread to do the passivation. Simpler code. Maybe
> > I'm missing
> > something. The above code protects a concurrently accessed
> > bean from being
> > passivated, doesn't it?
>
> Well, you're right: simpler code.
> For commit C you add the passivation time to every invocation
> (even if it's
> small).
Damn! I didn't think about the penalty of the added time to every
invocation. But...CMP does nothing in passivation. And I also wonder how
many people actually do stuff in ejbPassivate, even for Stateful beans.
(OT, I'd be curious to know what kind of things people do in ejbPassivate).
Also, you don't get this penalty with option A and B. I've been telling
Marc that "one size does not fit all" as far as caching, locking and
passivation goes. The logic should really be different and streamlined for
each commit type.
> Furthermore, allows setting the passivation thread to a lower
> priority than
> the invocation thread, reducing cache contention due to passivation.
Yeah, the way the code currently works the PassivationJob and cache.release
can be in contention with the cache. Is this what you mean? Plus with
commit option C and entities there is really no need for a cache other than
to figure out if a bean is already part of the transaction.
> Anyway it's an interesting point to debate, if it's worth removing the
> complexity and loose some speed, or not.
>
So the speed loss is just the penalty of calling passivate with every method
invocation with commit option C? Unless something funky is being done with
ejbPassivate, the penalty of always calling ejbLoad just plain dwarfs the
penalty of calling passivate. So, will calling passivate really effect
performance?
> I'll think some more on it.
>
Hey, thanks for discussing this. I hope my input is helpful.
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
