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.
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
