Hi,
I tend to agree with Dan O'Connor that the general solution for avoiding
these issues should be spec compliant, if possible. And if the commit C
option is a workable solution then we should look into that direction.
However, as was pointed out, nothing stops you from creating your own
interceptor that solves your critical requirements today. If people find
the interceptor useful we will add it to the distro. Not as a default as
part of the standard interceptor chain but as a configurable option.
Staying spec compliant is important for us at this point though.
-- Juha
At 16:46 6.6.2001 +0100, you wrote:
>OK!
> I know that it is kind of controversial and that its spec violation and
>stuff but why can't we have multi threaded beans for read-only cases? Why
>should we be bothered about transactions? We don't lock the database for
>selects do we? Non-purists who face real world performance issues - please
>let me know if these is complete rubbish or is something that 'could' prove
>useful...... unless someone voluteers to write the code for multiple bean
>instances per home handle!
>
>
>Vinay
>----- Original Message -----
>From: "Georg Rehfeld" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Wednesday, June 06, 2001 1:35 PM
>Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
>
>
>> 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
>
>
>_______________________________________________
>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
