Happy Business Starts Here

Zuora Support

Large Renewal Quote preview failed with optimistic locking error

Problem:

A Renewal Quote has approx 200 remove amendments, 200 update amendments, 200 add product amendments.

 

While previewing this large renewal quote, we are receiving below error message

 

Zuora - Object of class [com.zuora.zbilling.account.model.BillingAccount] with identifier [8a80c1156a3abc0b016a9e1b68d94914]: optimistic locking failed; 
nested exception is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction

 

The error didn't occur when we previewed the quote again.

Please let us know the root cause of this issue.






If you found my answer helpful, please give me a kudo ↑
Help others find answers faster by accepting my post as a solution √

1 REPLY 1
Zuora Support

Re: Large Renewal Quote preview failed with optimistic locking error

Root Cause & Solution:

A Bill run was running simultaneously for the same Customer Account in Zuora at the time of previewing the quote in SFDC.

 

This is an object locking issue where the system is unable to obtain a lock the subscription or account object because (presumably) there's another in-flight process already posting an update. The lock effectively stops the progress of the API so nothing executes as a result. It is fine to retry.

This is a Preview() call with Preview Option set to true, however, even when previewing a Subscription, the system would need to lock the table and do the calculation, because the preview is behaving like an Invoice generation action but the difference it that it will not generate a real Invoice.

 

Considerations to resolve or address:

This is not necessarily considered a Zuora issue, but rather one of API call sequencing and timing. There are a number of approaches to limit your exposure. Here are some ideas:
● Review API transaction processing to ensure you aren’t overlapping competing calls. In some cases, you may need to switch certain events from parallel to serial processing to eliminate overlap

● Insert a short wait for select transaction sequences if subsequent updates are prone to the error

● Insert retry() logic for transactions which receive the error. ​Limited retry with back-off is recommended. E.g., retry after 1 second, then 2 seconds, then 4, then 8, then fail.

 

Attached the document regarding this error for reference.






If you found my answer helpful, please give me a kudo ↑
Help others find answers faster by accepting my post as a solution √