Hi *,
while running ECperf against JBoss 2.4.4 or 2.4.6 I get lots of Exceptions in the Manufacturing domain. Funny enough, all of these are of the same kind:
<StackTrace>
L1:0: Error occured in scheduleWorkOrder
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
javax.transaction.TransactionRolledbackException: null
Embedded Exception
null
Embedded Exception
null
Embedded Exception
Optimistic concurrency control failed ; nested exception is:
javax.ejb.EJBException: null
Embedded Exception
Optimistic concurrency control failed ; nested exception is:
javax.ejb.EJBException: null
Embedded Exception
null
Embedded Exception
Optimistic concurrency control failed ; nested exception is:
javax.ejb.EJBException: null
Embedded Exception
Optimistic concurrency control failed ; nested exception is:
javax.ejb.EJBException: null
Embedded Exception
null
(... this is repeated some more times for a given Exception ...)
</StackTrace>
From this I gather that there have been conflicting updates, so that the transaction has to be rolled back.
Has anyone encountered the same problem yet? I am using CMP, ECperf 1.1, Oracle 8.1.7, JDK 1.4, J2EE 1.3.1
There are no exceptions in the orders domain.
I'm looking for suggestions where and how to fix this problem.
Thanks in advance,
Lars
-
Optimistic transaction fails (1 messages)
- Posted by: L Stitz
- Posted on: May 17 2002 05:24 EDT
Threaded Messages (1)
- Optimistic transaction fails by Tony Brookes on June 12 2002 21:27 EDT
-
Optimistic transaction fails[ Go to top ]
- Posted by: Tony Brookes
- Posted on: June 12 2002 21:27 EDT
- in response to L Stitz
Looks to me like you are having TX_SERIALIZABLE issues.
With Oracle, if you are using that isolation level, then it WILL allow two transactions to proceed at the same time, on the same data. BUT, when it tries to commit the second one it will moan that it can't serialize the transactions.
Note you don't get this behavior by default with SQL Server or Sybase as they use pessimistic concurrency.
You can either retry your transaction again, or just wig out and throw the problem up a layer (as you are doing now.) Which one you choose really depends on who should make the decision as to what to do...
HTH
Chz
Tony