Understanding Repeatable Read in OceanBase Oracle Mode and the Correct JDBC Configuration

Background : OceanBase Oracle mode officially supports only two isolation levels—Read Committed and Serializable—yet customers often need MySQL‑style Repeatable Read. The issue arises when a Java application using conn.setReadOnly(true) expects the same snapshot for repeated queries but does not see the expected behavior.

Analysis :

In a read‑only transaction, OceanBase uses a single snapshot, guaranteeing that repeated queries see the same data.

The JDBC call chain is Hikari → OceanBase‑client → setReadOnly → setSessionReadOnly , which ultimately executes set session transaction read only .

The two commands differ:

set transaction read only applies only to the current transaction; the setting is lost after COMMIT/ROLLBACK.

set session transaction read only applies to the entire session until it is changed or the session ends.

Only the SET TRANSACTION form can obtain a snapshot for repeatable‑read semantics.

Correct Configuration :

To achieve true repeatable‑read behavior in OBOracle, you must:

Set conn.setReadOnly(true) (which issues set session transaction read only ).

Add the JDBC option oracleChangeReadOnlyToRepeatableRead=True (available from oceanbase‑client 2.3.8).

When this option is enabled and isOracleMode=true , the driver translates the read‑only flag into SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ , which OceanBase treats as snapshot isolation.

Repeatable Read vs. Serializable :

OceanBase implements only RC and Serializable; when RR is requested, Serializable (implemented as Snapshot Isolation) is used, which is stricter than true RR.

Conclusion :

For Java applications accessing OceanBase Oracle mode, achieving Repeatable Read requires both conn.setReadOnly(true) and the JDBC option oracleChangeReadOnlyToRepeatableRead=True . The session will show isolation level REPEATABLE‑READ, though internally it is realized via Snapshot Isolation.