Discussions

Performance and scalability: Optimistic transaction fails

  1. Optimistic transaction fails (1 messages)

    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
  2. Optimistic transaction fails[ Go to top ]

    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