Transaction Serializable Isolation Level

Question

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE;

Question1 :

T1 (transaction 1) and T2 (transaction 2)

T1 : select * from tableName where status = 'A';

T2 : insert into tableName(id, status) values (1, 'I');

T2 : commit;

T1 : select * from tableName where status = 'I'; // Why T1 can not get the record with status I committed by T2 ? Is this because the snapshot created by T1 and what's the scope of this snapshot, the whole table?

Question2 :

T1 : insert into tableName(id, status) values (1, 'I');

T2 : insert into tableName(id, status) values (1, 'I'); // T2 is blocked if id is unique. Why T2 blocked? Because as I know, both transactions create a snapshot, even they have not committed yet.

Are there any locks take the participant in this scenario? Thanks.

Answer 1

T1: select * from tableName where status = 'I'; // Why T1 can not get the record with status I committed by T2? Is this because the snapshot created by T1 and what's the scope of this snapshot, the whole table?

Because SERIALIZE transaction can see the data committed before the transaction started or whatever changes made by the transaction itself. That is why T1 is not able to see the Record I as it was inserted after the T1 transaction is started.

Answering your second question,

T2: insert into tableName(id, status) values (1, 'I'); // T2 is blocked if id is unique. Why T2 blokced? Becase as I known, both transaction create an snapshot and they even have not commit yet.

Even though both the transactions are SERIALIZE, Oracle maintains integrity and will not allow violating any constraint. So you can not add record I in your T2 transaction which violates any constraint.

Answer 2

1. Is this because the snapshot created by T1

yes

2. and what's the scope of this snapshot, the whole table?

SCN

Question2: Why T2 blokced?

Because you have unique or primary key constraint and it's not deffered.

Answer 3

Following what SERIALIZABLE means:

SERIALIZABLE. This is generally considered the most restrictive level of transaction isolation, but it provides the highest degree of isolation. A SERIALIZABLE transaction operates in an environment that makes it appear as if there are no other users modifying data in the database. Any row you read is assured to be the same upon a reread, and any query you execute is guaranteed to return the same results for the life of a transaction.

Question 1

So in T1 you will not get any change made by T2, because your transaction level is SERIALIZABLE. That isolation level assures your query will always return the same results. Side effects, or changes, made by other transactions aren't visible to the query no matter how long it has been running.

Serializable isolation is suitable for environments:

• With large databases and short transactions that update only a few rows
• Where the chance that two concurrent transactions will modify the same rows is relatively low
• Where relatively long-running transactions are primarily read only

Regarding your second question, the row will be locked after a commit is executed, but the row won't be visible for T2.

More information here and a good example:

https://docs.oracle.com/cd/E25054_01/server.1111/e25789/consist.htm#BABCJIDI

Section 9.3 Read Consistency and Serialized Access Problems in Serializable Transactions