> On Jul 15, 2026, at 10:34, Mihir Kandoi <[email protected]> wrote:
> • Is READ COMMITTED actually a better solution or should we go with
> retrying transactions?
There's nothing specific about ERP platforms regarding the transaction
isolation mode, and READ COMMITTED isn't "better" than REPEATABLE READ or vice
versa. It's a matter of what semantics you want for transactions: do you want
a persistent snapshot that does not change (in from the perspective of the
session with the open transaction) between statements, or can your application
tolerate that?
In general, you want to use the weakest transaction isolation mode that gives
you the semantics that you want. If your application is written to expect that
the snapshot of the database does not change during the course of the
transaction, you'll need REPEATABLE READ, and then need to come up with a
solution for the serialization errors that you receive.
The source of serialization failures in REPEATABLE READ is two sessions
attempting to update the same rows. That's probably the issue you should
consider tracking down, since that has plenty of other potential problems (lock
waits, deadlocks) apart from REPEATABLE READ.
