> On Jul 15, 2026, at 10:34, Mihir Kandoi <kandoimihir@gmail.com> 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
persistentsnapshot 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
applicationis written to expect that the snapshot of the database does not change during the course of the transaction,
you'llneed 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
probablythe issue you should consider tracking down, since that has plenty of other potential problems (lock waits,
deadlocks)apart from REPEATABLE READ.
