RE: [JBoss-dev] Fw: Caching - Locking - Server Dies!
no the
code is the mutex stuff that always lets one thread through, and even though one
is working below on the code (outside the mutex) you can't get the real lock
since your current thread is actually second ..
marcf
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
Vinay MenonSent: Monday, June 04, 2001 1:19 PMTo: User @
JBoss; Dev @ JBossSubject: [JBoss-dev] Fw: Caching - Locking -
Server Dies!
Hi,
The following seems to be the code,
// Get
context
ctx = cache.get(key);
// Do we have a running transaction with the
context
Transaction tx =
ctx.getTransaction();
if (tx != null
// And are we trying to enter with another
transaction
!tx.equals(mi.getTransaction()))
{
// Let's put the thread to sleep a lock release will wake the
thread
// Possible
deadlock
Logger.debug("LOCKING-WAITING (TRANSACTION) for id "+ctx.getId()+" ctx.hash
"+ctx.hashCode()+" tx:"+((tx == null) ? "null" : tx.toString()));
// Try your luck
again
ctx =
null;
continue;
for the EntityInstanceInterceptor that actually causes this condition. I
have NOT specified any assembly descriptors in my ejb-jar.xml. What
transaction mode does JBoss then default to?
Vinay
- Original Message -
From: K.V. Vinay Menon
To: User @ JBoss ; Dev @ JBoss
Sent: Monday, June 04, 2001 5:58 PM
Subject: 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 10.
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
RE: [JBoss-dev] Fw: Caching - Locking - Server Dies!
For
stateless and stateful beans the default transaction mode is
Required.
Bill
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
Vinay MenonSent: Monday, June 04, 2001 1:19 PMTo: User @
JBoss; Dev @ JBossSubject: [JBoss-dev] Fw: Caching - Locking -
Server Dies!
Hi,
The following seems to be the code,
// Get
context
ctx = cache.get(key);
// Do we have a running transaction with the
context
Transaction tx =
ctx.getTransaction();
if (tx != null
// And are we trying to enter with another
transaction
!tx.equals(mi.getTransaction()))
{
// Let's put the thread to sleep a lock release will wake the
thread
// Possible
deadlock
Logger.debug("LOCKING-WAITING (TRANSACTION) for id "+ctx.getId()+" ctx.hash
"+ctx.hashCode()+" tx:"+((tx == null) ? "null" : tx.toString()));
// Try your luck
again
ctx =
null;
continue;
for the EntityInstanceInterceptor that actually causes this condition. I
have NOT specified any assembly descriptors in my ejb-jar.xml. What
transaction mode does JBoss then default to?
Vinay
- Original Message -
From: K.V. Vinay Menon
To: User @ JBoss ; Dev @ JBoss
Sent: Monday, June 04, 2001 5:58 PM
Subject: 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 10.
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-dev] Fw: Caching - Locking - Server Dies!
Hi,
The following seems to be the code,
// Get
context
ctx = cache.get(key);
// Do we have a running transaction with the
context
Transaction tx =
ctx.getTransaction();
if (tx != null
// And are we trying to enter with another
transaction
!tx.equals(mi.getTransaction()))
{
// Let's put the thread to sleep a lock release will wake the
thread
// Possible
deadlock
Logger.debug("LOCKING-WAITING (TRANSACTION) for id "+ctx.getId()+" ctx.hash
"+ctx.hashCode()+" tx:"+((tx == null) ? "null" : tx.toString()));
// Try your luck
again
ctx =
null;
continue;
for the EntityInstanceInterceptor that actually causes this condition. I
have NOT specified any assembly descriptors in my ejb-jar.xml. What transaction
mode does JBoss then default to?
Vinay
- Original Message -
From: K.V. Vinay Menon
To: User @ JBoss ; Dev @ JBoss
Sent: Monday, June 04, 2001 5:58 PM
Subject: 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 10. 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
