Recovering from transaction failures due to optimistic locking (2024)

Procedure

• Serialization

  This first strategy is to serialize the transaction that is failing. Serialization enforcesthe order of operations on the database to ensure that no other transactions update the same resultset between the time a transaction reads and writes a result set. In other words, serialization overa certain set of database operations offers the temporary reversal of the freedom that optimisticlocking offers.

  For example, if many different users perform a certain transaction often, thelikelihood of having collisions during the same set of operations is high. Serialization helps byfunneling users through that section of operations one-at-a-time by temporarily switching to a morepessimistic strategy over that critical section of code.

  See Also

  Troubleshooting Failed Transactions - Technical Documentation For IFS CloudCompensation Transaction Patterns - The Key to Handling Failures in Distributed ApplicationsFailed TransactionTransaction Risk: Meaning, Overview and FAQs

  Serialization is of benefit when:

  • The transaction is critical in nature, and you do not want to fail on criticaltransactions.
  • The update to the database is likely to have a high frequency of collisions.

  Note: By default, the INVENTORY table is serialized using select forupdate.

  Serialization can increase throughput for that operation when the error rate ishigh without it (that is, frequent collisions occur) by avoiding retrying the operation.

  Theappearance of one of the following exceptions in the HCL Commerce log indicates that anoptimistic update failure might have occurred:

  com.ibm.ejs.persistence.OptimisticUpdateFailureException: executeUpdate returned zero rowsupdated

  The exception when the failure occurs when the EJB container attempts to update the entitybean.

  com.ibm.commerce.base.helpers.ECJDBCOptimisticUpdateFailureException

  The exception when the failure occurs when a session bean attempts to update a row in a databasetable using a JDBC database connection.

  To force (or serialize) the SELECT and UPDATE statements to occur one after the other, changethe isolation level of the current operation to ReadStability.

  • Change the problematic SELECT statement to SELECT . . . FORUPDATE WITH RS.
  • Change the SELECT statement to SELECT . . .FORUPDATE.

  Note: For the serialization of EJB beans, do not modify existing beans. Instead, introduce JDBCqueries that use SELECT ... FOR UPDATE, as shown in the precedingexample.

  See Also

  I made a payment. My account has been debited but the transaction failed. What should I do?
• Retry

  The second strategy is to retry the command that fails. There is a mechanism in theTransaction server engine that allows you to rerun a command on failure.

  See the Making controller commands retriable.

  The defaultvalue for the retriable property is true. A command implementation can override this value, althoughthe normal way to override without changing any code is to explicitly specify it in the CMDREGdatabase table PROPERTIES column value. For example, if the CMDREG.PROPERTIES column value specifiesretriable=false, then the command will not be retried when its database transaction rolls back.

  Retrying a command that is failing is beneficial when there is a low probability ofcollision. Retrying a command is more expensive relative to serialization, but for infrequentlycolliding operations, it is preferable.

• Ignore

  If the transactions that are failing are insignificant (end users can refresh theirbrowsers and continue) you can ignore the error.