|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
|Burke
|Sent: Thursday, July 19, 2001 4:59 PM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] new wait(1000) not good
|
|
|Yeah, sure, having multiple instances makes things easier, they
|can only be
|applied to commit option B and C. For option A, you're going to need to
|share instances and thus you'll need some locking mechanism. I
|totaly agree
|though, for B and C, let the datastore manage locks and serialization.
interesting.
Let's finish and stabilize the 2.* series. This will need to go in the new
3.* series where we can rethink locking and clustering. A locking that will
support distribution and multiple instances will be interesting.
we will also slow down on versioning. Major updates like this are better
served in a new full revision. I anticipate a 6mo cycle,
marcf
|
|Bill
|
|> -----Original Message-----
|> From: [EMAIL PROTECTED]
|> [mailto:[EMAIL PROTECTED]]On Behalf Of James
|> Cook
|> Sent: Thursday, July 19, 2001 4:30 PM
|> To: [EMAIL PROTECTED]
|> Subject: RE: [JBoss-dev] new wait(1000) not good
|>
|>
|> 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
|>
|
|
|
|_______________________________________________
|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
