- What's wrong with doing a Context lock, but not doing a transactional lock
for read-only beans? If you do this you'll still be spec compliant,
correct? How would this affect your performance results? I'm pretty sure
the spec says it's up to the Container developer to decide how to synch
beans per transaction, but you are required to make EntityBeans single
threaded.
- Which xml file has the flag (isReadOptimized)? IMHO, if this read-only
thing is accepted, this flag for it should be in jboss.xml, not jaws.xml, so
that BMP developers have access to it.
- All in all, IMHO, Transactional EntityBean locking should be removed
totally from JBoss. This locking is totally useless when you have more than
one instance of JBoss hitting the sam DB anyways. Let the DB handle the
locking. If you want your EntityBeans synched across transactions use the
select-for-update options if you're using CMP, or with BMP, manage the DB
locks yourself.
Regards,
Bill
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
> Vinay Menon
> Sent: Wednesday, June 06, 2001 11:46 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
>
>
> 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
