Ok,
I know that reentrant beans can be quite a dangeroud beast at times.
What if?
1. I create a bean and in the ejb-jar deploy it under 2 names - one
reentrant and one not reentrant.
2. The re-entrant bean is used only for reads and the other one for writes.
Does this sound complete rubbish?
Jboss I believe creates only one bean even with commit option c. Why? Why
can't we have multiple instances? Performance sucks with non-reentranet
beans under high loads due to locking of the single instance.
3. Why can't we use the read-only flag to prevent locking?
4. Option D would do cache refreshes at fixed rates. But that sits after the
EntityInstanceInterceptor and locking is done in the
EntityInstanceInterceptor .
Vinay
----- Original Message -----
From: "Dan OConnor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 2:19 PM
Subject: RE: [JBoss-dev] Caching - Locking - Server Dies!
> Hi,
>
> A single component instance should only handle one request (i.e.
> one thread) at a time, regardless of whether or not it is read only.
> There is already an option to let the database handle
> synchronization: commit option "C". (Obviously the component
> must cooperate for read-write operations, either through optimistic
> or pessimistic locking.)
>
> If the component uses commit option "C", it is allowable to have
> multiple instances of a particular entity component associated with
> the same primary key within a home. This is how to handle
> concurrency of client requests for a single "glob of data"; not
> through multiple threads in one component.
>
> Unfortunately, I think that JBoss still only allows one entity per key
> within a home, even with commit option "C". If this is true, IMHO it
> would be the best point of attack for this problem.
>
> Later, we can add a cache that might save on database hits for
> read-only or read-mostly entity beans, duplicating some of the
> speed advantages of commit option "A", without the scaling
> disadvantages. Or for true read-only beans, we can allow commit
> option "A" with multiple instances. Or in certain application
> circumstances where perfect data consistency is not a design
> goal, we can use commit option "D" with multiple read-write
> instances, each with its own state cache maintained between
> requests.
>
> -Dan O'Connor
>
> On 4 Jun 01, at 21:47, Bill Burke wrote:
>
> > Vinay,
> >
> > I'm pretty sure the EJB spec says that an instance of an EntityBean can
only
> > process one request at a time. I think this is what the Context lock is
> > for.
> >
> > When you say that your bean is readonly, you mean that you defined it in
> > JAWS as readonly? I'm pretty sure the code does NOT check to see if the
> > EntityBean is JAWS and therefore doesn't check to see if it is readonly.
> >
> > IMHO, there should be an option to remove EntityBean locking and let the
> > Database handle the synchronization either through the select-for-update
> > option, or doing the locks in BMP.
> >
> > Bill
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
> > Vinay Menon
> > Sent: Monday, June 04, 2001 6:17 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] Caching - Locking - Server Dies!
> >
> >
> > Bill,
> > I have tried both options. Started without a container transaction
> > defined. In which case it kept throwing LOCKING-WAITING transactions [
from
> > the EntityInstanceInterceptor] which says that JBoss is creating a
> > transaction automatically. Next I changed the ejb-jar to specify the
> > container transaction as REQUIRESNEW and as expected it did create a new
> > transaction and hence showed the same messages. Finally, changed the
> > container transaction to SUPPORTS when it stopped locking for the
> > TRANSACTION and started locking waiting for the CTX [Context] in the
else
> > clause of the EntityInstanceInterceptor's invoke method. So there you
go.
> > Why is it locking for readonly bean? Why does it need to do it? The
effects
> > are only marginal and hardly detectable at low loads. It is more
pronounced
> > at higher loads and as the table size increase it goes into a real
> > amplifying loop where the beans wait and take longer to return and that
in
> > turn cause the lock to be longer and so on.
> >
> > Strange that the method does not check for read-only attribute either?
Why
> > is that?
> >
> > Vinay
> > ----- Original Message -----
> > From: Bill Burke
> > To: [EMAIL PROTECTED]
> > Sent: Monday, June 04, 2001 9:10 PM
> > Subject: RE: [JBoss-dev] Caching - Locking - Server Dies!
> >
> >
> > If an Entity is loaded within a transaction it is locked until the
> > transaction completes.
> >
> > Bill
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
> > Vinay Menon
> > Sent: Monday, June 04, 2001 12:59 PM
> > To: User @ JBoss; Dev @ JBoss
> > Subject: [JBoss-dev] Caching - Locking - Server Dies!
> >
> >
> > Hello Folks,
> > Continuing with my load test I find something strange. I have
a
> > test harness that simulates 100 clients hitting the server at 100ms.
They
> > all retrieve the same data - 150 odd records - from the database. The
> > cache size has been set to 100000. Commit option is A. Am not doing any
> > write operations.
> >
> > 1. The retrieve for the first client is high as expected.
> > 2. This then falls rapidly to about 90ms.
> > 3. However the response time then rises to aout 20 seconds.
> >
> > On checking the server log, I am getting loads of 'LOCKING-WAITING
> > (TRANSACTION)' messages. And its due to this locking I presume that the
> > response time takes a beating.
> >
> >
> > a) Why is it not just reading data from cache?
> > b) Why is it locking for read only opertions?
> >
> > Why is this so? All this seems very strange. Either I am missing
> > something or the caching is not working for high loads.
> >
> > Regards,
> >
> > 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
