All of this entity contention is an optional thing we will have to
explicitly "turn on", correct?
I prefer to have the container create multiple instances of identical
entities (same home, same pk) and handle the concurrency in the database.
jim
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> M Stark
> Sent: Tuesday, July 17, 2001 10:45 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] new wait(1000) not good
>
>
> Because Thread.yield() does not prevent busy waiting. Using a
> wait(N) there
> can be no deadlock as this will timeout in N milliseconds. I am
> actually just
> going to do a Thread.sleep(1) as this results in no cpu
> utilization and 1 ms
> is a small performance penatly for the contending caller.
>
> To see the problem with using Thread.yield(), try this simple program:
>
> tmp 1046>cat tstYield.java
>
> class tstYield implements Runnable
> {
> static long start;
>
> static void yield()
> {
> Thread.yield();
> }
> static void sleep()
> {
> try
> {
> Thread.sleep(1);
> }
> catch(InterruptedException e)
> {
> }
> }
>
> public void run()
> {
> System.out.println("Start "+this);
> long elapsed = System.currentTimeMillis() - start;
> while( elapsed < 10000 )
> {
> yield();
> elapsed = System.currentTimeMillis() - start;
> }
> System.out.println("End "+this);
> }
>
> public static void main(String[] args)
> {
> start = System.currentTimeMillis();
> for(int t = 0; t < 2; t ++)
> new Thread(new tstYield(), "T"+t).start();
> }
> }
>
> When the threads attempt to pause using yield() rather than
> sleep(), there is
> 100% cpu utilization of the 10 sec period this program runs. When the use
> sleep() there is no cpu utilization of the 10 sec period.
>
> ----- Original Message -----
> From: "Bill Burke" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, July 17, 2001 4:25 PM
> Subject: RE: [JBoss-dev] new wait(1000) not good
>
>
> > Why not just a Thread.yield after mutex.release? With
> sleeping, don't you
> > run the risk of starving out threads if the same EntityBean
> keeps on being
> > accessed continually?
> >
> > I'm also worried about this same scenario with the new locking
> stuff in the
> > mainline. With notifyAll instead of just notify is there a
> chance to starve
> > threads? With notify aren't you guarateed FIFO for lock
> contention, but you
> > wouldn't be guaranteed with a notifyAll?
> >
> > Bill
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On
> Behalf Of Scott
> > > M Stark
> > > Sent: Tuesday, July 17, 2001 6:22 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [JBoss-dev] new wait(1000) not good
> > >
> > >
> > > Ok, I missed that mutex acquire at the start. I care less about
> > > slowing down the
> > > performance in the case of contending access than I do about burning
> > > 100% cpu waiting for contention to resolve. Even a 10ms wait
> should remove
> > > the spinning cpu so I'll stress test the issue by back porting
> > > the latest lock
> > > test from jbosstest to find a happy medium between
> performance throughput
> > > and wasted cpu. I'll also just sleep the current thread after the
> > > release of the
> > > mutex.
> > >
> > > ----- Original Message -----
> > > From: "Bill Burke" <[EMAIL PROTECTED]>
> > > To: "Jboss-Development@Lists. Sourceforge. Net"
> > > <[EMAIL PROTECTED]>
> > > Sent: Monday, July 16, 2001 10:02 PM
> > > Subject: [JBoss-dev] new wait(1000) not good
> > >
> > >
> > > > Scott,
> > > >
> > > > Your 2.2 wait(1000)change will seriously slow down applications
> > > that contend
> > > > for the same Entity. In fact, it may even deadlock if
> requests for that
> > > > Entity keep on coming in.
> > > >
> > > > The do..while loop does a mutex.acquire at the beginning. It
> > > will not do a
> > > > mutex.release until after the 1 second is up. If the
> transaction that
> > > > currently holds the Entity invokes on the Entity more than one
> > > time, it will
> > > > be waiting for any thread currently hold the mutex to finish.
> > > >
> > > > Also, the mutex is acquired again in the finally clause of
> > > > EntityInstanceInterceptor to synchronize on ctx.unlock and such.
> > > >
> > > > 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
> >
>
>
> _______________________________________________
> 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
