Transaction Isolation Level in ODI

Transcription

1 In this post I will be explaining the behaviour in Oracle 11g and regarding the ODI versions, there is not much difference between ODI 11g and 12c. If you see the drop down in 11g ( ) procedure, it has 6 options as shown below. where as in 12c (12.2.1) the display options has changed slightly. As per documentation NONE is now deprecated. NONE: Deprecated in release with no direct replacement and will be removed soon, existing values will be changed to null DEFAULT: default mode will be used (i.e. DB or driver specific) READ_UNCOMMITED: The transaction can read data not committed by another transaction. READ_COMMITED: The transaction can only read data committed by other transactions (in general, this is the default mode of many data servers. REPEATABLE_READ: The transaction is certain to read the same information if it executes the same SQL query several times, even if the rows have been modified and committed by another transaction in the meantime. SERIALIZABLE: The transaction is certain to read the same information if it executes the same SQL query several times, even if the rows have been modified, deleted, or created and committed by another transaction in the meantime. NONE: none At this moment Oracle only supports READ_COMMITED, SERIALIZABLE. NONE, DEFAULT and READ_UNCOMMITED is not supported. If you will try with any of these options, you will see below error.

2 Also there is a justification for READ_UNCOMMITED as Oracle never permits dirty reads. So we will be looking at READ_COMMITED, SERIALIZABLE. The READ_COMMITED is the default one and hence it will always read the committed data from a table. That means even if you have different transactions, it will still read the data committed by other transaction. I have created below procedure for this demonstration. I guess I don t need to give explanation as this is quite straight forward. Notice the difference between step 20 and 50. Both are having different transaction and in step 50 the isolation level is READ_COMMITED. Even if you won t select READ_COMMITED, this will be taken as default.

3

4 in the above screenshot I am creating a table TESTISOLATION and inserting a value as 1 using transaction zero. The commit option is set to COMMIT. Now in the next step, I am selecting the value with another transaction and inserting it to a table called TESTISOLATION1. If you will try to execute the procedure you can see value inserted in TESTISOLATION1 table and of course this is expected. Now let s see the SERIALIZABLE one.

5 As I have already mentioned that in case of SERIALIZABLE, transaction is certain to read the same information if it executes the same SQL query several times, even if the rows have been modified, deleted, or created and committed by another transaction in the meantime. So let s try to read the data in one transaction, then delete in another transaction followed

6 by a commit. Then again read it in the previous transaction. If we can still see it, then that will justify the above statement. If you see the above screenshot, in step 20 I am trying to insert 1 to the TESTSIOLATION table using Transaction 0 with COMMIT. In step 30, I am selecting the value using Transaction 1 and Isolation Level as SERIALIZABLE. This step should keep the values in that session without being affected by other sessions. In step 40, I am deleting the value using Transaction 0 with COMMIT. This means now there is nothing in the table as I am committing the DML operation. In step 50, I am again selecting the values using Transaction 1 and Isolation Level as SERIALIZABLE (See Command on Source tab). Well this is quite interesting here. Even if we have deleted the rows in previous step the value is still available in this transaction. If you run this procedure you can see no row in TESTSIOLATION and one row in TESTSIOLATION1.