Georg Rehfeld wrote:
> I still would insist on the correction of the missing wait/notify
> issue, as I still believe that the extremly bad response times
> under load are more caused by several threads executing tight
> loops consuming most of the cpu time instead of simply waiting
> and let the cpu to JBoss doing real work!
It certainly can't help!
>
> I'm NOT a multithreading expert though. My first thought was to
> simply insert a wait() directly after the two
> Logger.debug("LOCKING-WAITING ..."); calls and a notifyAll()
> after the ctx.unlock() in the finally clause, but I've 2 problems
> with this approach:
>
> 1. there is a mutex.aquire()/mutex.release() pair; when I simply
> would wait inbetween, I think no other thread can enter the code
> thus rendering EntityInstanceInterceptor dead, when one thread is
> waiting, on the other hand, I can't simply release the mutex
> there, it's a critical section. A solution would be to have a
> wait directly before the } while (ctx == null); if ctx == 0 as of
> this (hand made) context diff:
>
> catch (InterruptedException ignored) {}
> finally
> {
> mutex.release();
> }
> + if (ctx == null) {
> + // let the thread that has the lock proceed
> + // at same time let's detect possible deadlock
> + long start = System.getCurrentTimeMillis();
> + try {
> + wait(DEADLOCKTIMEOUT + 1000);
> + }
> + catch (InterruptedException ignored) {}
One problem here is that when we're waiting on the context, we want to
wait on the context (i.e. "ctx.wait(DEADLOCKTIMEOUT + 1000)") Just doing
wait and notifyAll on the interceptor itself will involve all calls on
our entity when we just want to handle contention for the one context.
The other problem is that if we're waiting on the transaction, we don't
want to do wait/notify on the context - I don't know what we do want to
wait on, but we really need to know when the transaction ends.
Also, I'd do a notify, not a notifyAll - why schedule every thread to
run when only one will be able to run anyway?
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
