Oh yeah, one more point. Testing with Option C is also important because
Passivation is scheduled a lot more than with A or B.
Bill
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bill
> Burke
> Sent: Monday, July 02, 2001 12:31 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
> incomplete.
>
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> > fleury
> > Sent: Monday, July 02, 2001 11:56 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
> > incomplete.
> >
> >
> > |> I don't understand the second point, what do you mean the
> calls will be
> > |> serialized? please explain,
> > |>
> > |>
> > |
> > |My point was that if you're accessing the same entity with the
> > same primary
> > |key, the threads will be all queued up waiting on eachother. Only one
> >
> > it better! that is the spec!
> >
> > that's the way it is supposed to work, if it doesn't its a bug
> >
> > |thread will be able to run at one time since it would have a
> > transactional
> > |lock and/or method lock. Thus it doesn't matter if you run your
> > test with
> > |2, 5, 10, 50, 1000 concurrent threads, you will always have the
> > |same result.
> >
> > we hope so :)
> >
> > |Plus, you're not testing concurrent access of the cache, since all
> > |executions would happen in order.
> >
> > we *are* testing concurrent threads, and we hope they serialize.
> >
>
> That's just one test though. You're still not testing concurrent
> access of
> the cache with DIFFERENT primary keys. Although this is less of a problem
> now that you've removed the InstancePooling.
>
> > |I'm glad you got rid of the InstancePool :)
> >
> > yes does get rid of the complications (enjoyed your comments in the code
> > though :)
> >
> > |On a separate topic, why does AbstractInstanceCache.get(), have to
> > |unschedulePassivation? If a bean is not in the cache, why
> can't you just
> > |allocate a new one? This seems like another unnecessary complication.
> >
> > actually (working from memory) I thought that was one of the
> > elegant things
> > done by Simone, it works for both stateful and entity.
> >
> > Yes, sure, for entity you can just allocate a new instance and
> let ejbLoad
> > do its magic (reload state) but for the Stateful that has got
> to work (and
> > it does kudos to Simone there). It's quite ok actually.
> >
>
> Yeah, I guess it's cool now that you removed InstancePooling.
> God, pooling
> just fucked everything up and caused a lot of complexity. I wonder if
> pooling actually had any effect on performance anyways?
>
> Still, for Stateful beans, you're adding complexity for the time between
> when the Stateful bean gets scheduled for passivation, and when the
> Passivator Thread actually runs. Which is only a few milliseconds, right?
> If the Stateful bean is scheduled for passivation, this usually means that
> it has timed out. It seems with the unscheduledPassivation stuff, what
> you're really doing is just extending the configured timeout
> period. So why
> schedule passivation? Just do it. Am I making any sense here?
>
>
> Bill
>
>
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
