My view is if the new option to have multiple bean instances is going to
take long to write why should we be bothered about concurrency in a read
only bean?
Vinay
----- Original Message -----
From: "Dan OConnor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 1:26 PM
Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
> Hi,
>
> First of all, thanks for the contribution. Things get done when
> people jump in and contribute their time, and we definitely have a
> scaling problem we need to fix.
>
> If I understand the implications of your code, I'm very against this
> particular solution, as it is a violation of the EJB spec and will also
> create concurrency problems unless the EJB component is also
> written in violation of the spec. (This is nothing against you; this
> approach has been suggested before.)
>
> Bottom line: if I'm correct that this allows multi-threaded access to
> a single entity instance, I think you should take it out. The correct
> solution to the locking problem as I see it is slightly more work:
> add support for multiple instances of entities associated with the
> same primary key for commit option "C". See my previous post.
>
> Of course, others may disagree, so this is just my opinion. I hope
> Marc, Juha, Simone, Rickard, etc. will offer their opinions, as this
> is a pretty key piece of code. Maybe they can talk about it at Java
> One. :-)
>
> I might be wrong about what is going on, or about the ultimate
> utility of this piece of code. But it is a key piece of code for the
> container, and needs to be reviewed carefully.
>
> -Dan
>
> On 6 Jun 01, at 9:32, K.V. Vinay Menon wrote:
>
> > Hello,
> >
> > 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. Wou
> ld really appreciate if folks who really have the 'bigger picture' can let
me know.
> >
> > Thanks
> >
> > Vinay
> >
>
>
>
> _______________________________________________
> 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
