Hi Vinay,
see below
> In order to avoid locking for TX or CTX in the
> EntityInstanceInterceptor, I've basically added a flag to
> indicate whether the bean can be optimized for read only
> operation. In the EntityInstanceInterceptor, where the loop
> actually wait for the lock I've added a condition
>
> isReadOptimized = metadata.isReadOptimized();
>
> if(!isReadOptimized)
> {
> ...
> ...
> go about as usual trying to aquire lock etc
> }
>
> mi.setEnterpriseContext(ctx);
> return getNext().invoke(mi);
>
> and in the finally clause
>
> if (ctx != null && (!isReadOptimized))
> {
> //business as usual code
> }
>
> What is good is that I no longer have my response times creeping
> up under sustained loads. Does this look alright? Does anyone
> anticipate any other problems due to this. Would really
> appreciate if folks who really have the 'bigger picture' can let
> me know.
Might be better you provide a context diff to us, so we more
exactly can see what you plan to do (change code, do
cvs diff -u EntityInstanceInterceptor.java).
As far as I understand, you skip the whole
do { ... } while (ctx == null); loop? So you end up with a null
EnterpriseContext, not a good idea IMHO, because i.e. security
and transactional settings (amoung other important things) are
attached to it, most likely invoked other interceptors rely on
the ctx set?!
Where does your isReadOptimized come from, JAWS? If so, the BMP
developers are left alone.
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!
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) {}
+ finally {
+ if (System.getCurrentTimeMillis() - start
+ > DEADLOCKTIMEOUT)
+ {
+ throw new EJBException(
+ "possible deadlock detected");
+ }
+ }
+ }
} while (ctx == null);
...
...
else
{
// Yeah, do nothing
}
+ notifyAll();
}
catch (InterruptedException ignored) {}
finally
{
mutex.release();
}
2. the notifyAll() above better should not awake any thread in
JBoss, but better only the threads that wait above, hmmm, isn't
this implicit? Do we need thread groups? It would be
best/required that the Interceptor only waits, when the same bean
instance is to be entered concurrently (this should be so
already) and that only exactly the threads, that wait on the same
instance should wake up. Please remember, I'm unexperienced with
multithreding and JBoss, just lost on this.
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
