Serializable is the strictest transaction isolation level. It makes concurrent transactions behave as though they ran one after another. Unlike repeatable read, it also prevents phantom reads: a later query in the same transaction cannot suddenly return a row inserted by another transaction. section 11.2.1
Preventing a phantom row
Suppose a transaction queries for matching rows, then repeats that query before it finishes. Another transaction inserts a row that matches. Serializable isolation must prevent the new row from becoming visible to the first transaction’s repeated query. Row-level locks alone may not accomplish this; exclusively locking an entire table after a write is one crude possible mechanism, not a universal implementation. section 11.2.1
Table 11.1 ANSI isolation levels and the problems that they address (view table figure)
Compare which concurrency problems each ANSI isolation level prevents; serializable is the only level shown as preventing phantom reads. section 11.2.1
Choose the level with the DBMS’s behavior in mind. Stronger isolation can harm scalability under high concurrency, while insufficient isolation can leave difficult-to-reproduce bugs. Locking strategies and their performance effects vary by vendor, so check the DBMS documentation rather than assuming that serializable always uses a particular lock. section 11.2.1
Serializable mode can also be a deadlock-avoidance option when updating one row locks the whole table: a concurrent transaction waits for the first to finish. That depends on the DBMS’s locking behavior. Alternatives include taking an exclusive lock when selecting data or having Hibernate issue updates in primary-key order with hibernate.order_updates. section 11.2.4
