Oracle/toplink/internal/helper/ConcurrencyManager.acquire "Hang"

Question

Hi,
I am trying to test an application on WAS with some load (200 virtual users from a load-runner) experiencing a hand condition. There are 128 threads waiting with the below stack trace.
at java/lang/Object.wait(Native Method)
at java/lang/Object.wait(Object.java:199(Compiled Code))
at oracle/toplink/internal/helper/ConcurrencyManager.acquire(ConcurrencyManager.java:47(Compiled Code))
at oracle/toplink/internal/sequencing/SequencingManager.acquireLock(SequencingManager.java:487(Compiled Code))
at oracle/toplink/internal/sequencing/SequencingManager$ForcedToUseWriteAccessor_State.getNextValue(SequencingManager.java:678(Compiled Code))
at oracle/toplink/internal/sequencing/SequencingManager.getNextValue(SequencingManager.java:325(Compiled Code))
at oracle/toplink/internal/sequencing/ClientSessionSequencing.getNextValue(ClientSessionSequencing.java:76(Compiled Code))
at oracle/toplink/internal/descriptors/ObjectBuilder.assignSequenceNumber(ObjectBuilder.java:127(Compiled Code))
at oracle/toplink/publicinterface/UnitOfWork.assignSequenceNumber(UnitOfWork.java:297(Compiled Code))
I am using the following oracle version:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Windows Server 2003 Version V5.2 Service Pack 1
CPU : 4 - type 586, 2 Physical Cores
Process Affinity : 0x00000000
Memory (Avail/Total): Ph:1831M/3583M, Ph+PgF:3736M/5475M, VA:495M/2047M
The server slowly slips into a hang state and later becomes unresponsive.
I request you guys to provide an insight into the problem area here?
Thanks
Phani

Answer 1

Is the stack the same? There must be at least one thread that has the lock and is waiting on another resource to have a deadlock, could you include its stack.
What type of sequencing are you using, table or native (sequence object)?
Are you using JTA, and have you set a non-JTA read connection pool?
If you are using table sequencing and JTA, what could be occuring is a database deadlock on the sequence table. Some solution would be:
- Use native sequencing (sequence objects).
- Specify a sequence connection pool on your TopLink ServerSession using a non-JTA datasource or TopLink direct-JDBC connection pool.
You may also want to try using the TopLink 11g preview, it may not encounter the issue.