Transaction Management in general: Isolation Level

Hi, I’ve a general question concerning transaction management and isolation level.
I’m using the ActiveX component and Tamino version 3.1.1.1.

Session S1 is started with parameters InoProtected and InoLockWaitYes. Another session S2 can already read my uncommitted changes (dirty-read) even before I commit them. When I rollback my transaction the old values are in the database - which is correct.

But isn’t it the idea of the ACID concept to avoid other sessions seeing my uncommitted changes?

How do I have to set the isolation level and lock-wait parameters that I have real isolation?

In the manual it’s stated that a session S2 can still do an “unprotected read” when S1 has a protected session open. What does “unprotected read” mean in that sense, a dirty-read?

thanks for clarification, ren

Hi Rene,

I will try to comment on your remarks.

you wrote:
“But isn’t it the idea of the ACID concept to avoid other sessions seeing my uncommitted changes?”

True, transactions are there to provide isolation of modifications on data in a shared environment. There are several levels of isolation possible. You could argue that the possibility of no isolation (which is what unprotected in fact implies) is one of these possibilities or not. The fact is that Tamino offers this possibility to allow read applications, which do not have any isolation requirements to operate with the highest degree of concurrency, i.e. without the overhead of any locks.

You wrote:
“How do I have to set the isolation level and lock-wait parameters that I have real isolation?”

Currently, Tamino offers two settings of the isolation parameter which determines the type of locks Tamino uses and therefore provides isolation: shared and protected. In shared mode, shared locks are used for reading, write locks for update, insert and delete. Shared locks allow concurrent reading, write locks not. In protected mode, only write locks are used. So, using shared, you avoid dirty reads, and serialize concurrent transactions that want to update the same data. Using protected you serialize concurrent transactions that read the same data.

You wrote:
“In the manual it’s stated that a session S2 can still do an “unprotected read” when S1 has a protected session open. What does “unprotected read” mean in that sense, a dirty-read?”

Correct. unprotected means dirty read.

In the Tamino version planned for the end of 2002, more possibilities in the area of isolation levels will be made available.


best regards
Martin