What is the best default transaction isolation level for an ERP, if any?

Question

Short background: We are just starting to migrate/reimplement an ERP system to Java with Hibernate, targeting a concurrent user count of 50-100 users using the system. We use MS

Answer 1

Read Uncommitted is definitely the underdog in most forums. However, there are reasons to use it that go beyond a matter of "speed versus accuracy" that is often pointed out.

Let's say you have:

• Transaction T1: Writes B, Reads A, (some more work), Commit.
• Transaction T2: Writes A, Reads B, (some more work), Commit.

With read committed, the transactions above won't release until committing. Then you can run into a situation where T1 is waiting for T2 to release A, and T2 is waiting for T1 to release B. Here the two transactions collide in a lock.

You could re-write those procedures to avoid this scenario (example: acquire resources always in alphabetical order!). Still, with too many concurrent users and tens of thousands of lines of code, this problem may become both very likely and very difficult to diagnose and resolve.

The alternative is using Read Uncommitted. Then you design your transactions assuming that there may be dirty reads. I personally find this problem much more localized and treatable than the interlocking trainwrecks.

The issues from dirty reads can be preempted by

• (1) Rollbacks: don't. This should be the last line of defense in case of hardware failure, network failure or program crash only.

• (2) Use application locks to create a locking mechanism that operates at a higher level of abstraction, where each lock is closer to a real-world resource or action.