Hi Vinay, hi all,
sorry for being verbose (and GURUS, please at least read the tail
of this message).
> 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.
Bill Burke already answered a) and b): when you access a bean
inside a transaction the container MUST lock, even when reading,
so that you can modify the read data and write it back in the same
transaction, without having to worry another client has modified
the bean inbetween. And, the container has no knowledge at all,
that a method is read only, it ever must assume, that bean data
is modified (i.e. even a getter might set a 'last acessed' Timestamp
that must be written back to the DB).
The only exception to that rule is the JBoss specific boolean
isModified() method, which, when present in the bean impl and
returning false when the container invokes it at end of a
transaction causes the container to skip the ejbStore()/writing
to DB. You should implement that method for good performance.
(With 90ms might be you already have? But then, most DB's should
be able to do more than 20 transactions per second, even on
todays poor hardware, so might be you havn't it yet.)
> I have NOT specified any assembly descriptors in my ejb-jar.xml.
> What transaction mode does JBoss then default to?
The default is Required, thus your methods execute inside a
transaction. For testing read performance you migth specify
Never, Supports or NotSupported, but be aware, that the data
you get must NEVER be used to calculate and write back to the
bean, consider the data to be invalid, old, outdated, usable
only for rough display purposes, where seeing inconsistent data
migth be acceptable. Even without transactions have the
isModified() implemented, it will be respected (as of the code
somewhere).
You identified the code, that generates the LOCKING-WAITING
message correctly. Please note, that there still is an issue
with this code, there is a comment
> // Let's put the thread to sleep a lock release will wake the thread
but there actually is NO sleep in the code, causing the thread
to go into a tight loop, producing tons of LOCKING-WAITING
messages and consuming up to 90% of processor time. I don't know
why the wait was left out, maybe it was a planned feature and
forgotten about? There was a patch suggested some month (!)
ago to reduce the amount of messages to one start message and
one end message; this patch wasn't picked up by any developer,
I think, because it would tigthen the loop even more (as it is,
I believe the massive message amount leaves 10% CPU because of
waiting for IO).
So the correct solution for this issue would be a wait there
and the accompanying notify/notifyAll at the place, where the
lock is released. With that correction the LOCKING-WAITING
message would only appear once before the wait, making the
suggested patch unneccessary, and not eat up CPU anymore.
I believe that this would drastically change your response
times even when accessing the beans inside a transaction.
As I havn't digged deep enough into JBoss code (and have no
write access to CVS) I only can hope, that one of the gurus
sees this, picks it up and fixes it.
hope this helps
Georg
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
PS: Please report your stress test results on this list, I think
both, performance for accessing the beans inside and outside
a transaction, are very interesting.
PS2: Besides, that cited code mentiones a possible deadlock in
another comment, but there seems to be no deadlock resolving
code. I think, this too should be addressed soon, in a real app
with heavy load it's really likely, that deadlock can happen.
If your test clients i.e. access the same beans in random order
in ONE transaction (via session bean facade for instance) you
easily should be able to run into a deadlock.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
