Transaction Isolation

Transaction isolation is provided for all data manipulation language (DML) statements. Most data definition language (DDL) statements commit the current transaction. See the Grammar for details.

This database supports the following transaction isolation levels:

• Read Committed
  This is the default level. Read locks are released immediately after executing the statement, but write locks are kept until the transaction commits. Higher concurrency is possible when using this level.
  To enable, execute the SQL statement SET LOCK_MODE 3
  or append ;LOCK_MODE=3 to the database URL: jdbc:h2:~/test;LOCK_MODE=3
• Serializable
  Both read locks and write locks are kept until the transaction commits. To enable, execute the SQL statement SET LOCK_MODE 1
  or append ;LOCK_MODE=1 to the database URL: jdbc:h2:~/test;LOCK_MODE=1
• Read Uncommitted
  This level means that transaction isolation is disabled.
  To enable, execute the SQL statement SET LOCK_MODE 0
  or append ;LOCK_MODE=0 to the database URL: jdbc:h2:~/test;LOCK_MODE=0

When using the isolation level ‘serializable‘, dirty reads, non-repeatable reads, and phantom reads are prohibited.

• Dirty Reads
  Means a connection can read uncommitted changes made by another connection.
  Possible with: read uncommitted
• Non-Repeatable Reads
  A connection reads a row, another connection changes a row and commits, and the first connection re-reads the same row and gets the new result.
  Possible with: read uncommitted, read committed
• Phantom Reads
  A connection reads a set of rows using a condition, another connection inserts a row that falls in this condition and commits, then the first connection re-reads using the same condition and gets the new row.
  Possible with: read uncommitted, read committed