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
