Our procurement team is hitting database lock timeouts when multiple users try to edit the same purchase order simultaneously. We’re getting “Lock wait timeout exceeded” errors after about 50 seconds, and users lose their changes.
The issue happens most frequently during month-end when approvers are processing large batches of POs. We’re on ICS 2022 with default isolation level settings. Our custom extension uses Infor Extensibility Framework to add approval workflow logic.
PurchaseOrder po = PurchaseOrder.findByNumber(poNumber);
po.setApprovalStatus("APPROVED");
po.update(); // Lock timeout occurs here
Is there a way to implement optimistic locking or adjust isolation levels to handle concurrent edits better?
Also consider your transaction isolation level. The default REPEATABLE READ holds locks longer than necessary for most business operations. For approval workflows, READ COMMITTED is usually sufficient and releases locks much faster. You can set this at the connection level in your extension code without affecting the core CloudSuite behavior.
Thanks for the suggestions. I’m concerned about implementing version control - would that require schema changes to the core CloudSuite tables? We try to avoid customizing standard tables. Is there a way to handle this through extension configuration or application-level locking instead?
The default pessimistic locking in CloudSuite can definitely cause this. You need to implement optimistic locking with version control fields. Add a version_number column to your PO table and increment it with each update. Check the version before committing changes - if it’s changed, someone else modified the record. This prevents lock contention because reads don’t block other operations.