Operational semantics of transactions(7)

Mathematics is forcing towards a consistent framework of theory development. Computer Science is an engineering discipline and sometimes suffers from ad-hoc definitions. Transactions are a concept that is commonly used in the database area. It is often def

Log data for constraint checking:The data which are generated by the transaction must be checked.

We write all these data to the space Trans-fer4Write(transaction,location)).

Change space:The database system may also write data directly to the stable database.In this case, we record overwriting of data by the transaction using the space LogDB(transaction,location).

This space allows to undo the effects the trans-action caused in the secondary storage. Variables:The transaction may use additional vari-ables for computation.These variables belong to a transaction and have a location.We use the space CurrentDB(transaction,location)for recording.

Concurrency control data:The transaction machine may use also data for concurrency control of sets of competing transactions.Typical concurrency control data are lock data,i.e.the lock space Lock(location)partially assigning a location to

a transaction or the read-write-lock space Read-

Lock(location)which partially assigns a location to a set of transactions and WriteLock(location) which partially assigns a location to one transac-tion.

Most of the literature on TA uses only one or a small number of the variety.

It suffices to describe the meaning of the abstract operations in order to get the in-private setting: CreateOwnDB:

CurrentDB(Self,*):=undef

Transfer4Write(Self,*):=undef PrepareMergeDB:

FOR ALL x∈

(σT A=t(T ransfer4W rite))[Location]

∩StableDB[Location]

DO Ready2WriteDB(x):=

Transfer4Write(Self,x)

ENDDO

MergeOwnDB:

FOR ALL x∈Ready2W riteDB[Location] DO StableDB(x):=Ready2WriteDB(x)

ENDDO

FreeOwnDB:

//still do nothing here

CurrentDB(Self,loc):=StableDB(loc) WriteOwnDB(where:Location,val:Value):

Transfer4Write(t,loc):=CurrentDB(t,loc)

We observe now

OwnDB=StableDB∪

((σT A=t(T ransfer4W rite))[Location]

∩StableDB[Location]) Proposition1If the run of transactions t1,...,t k is applicable then the transition by the transactions t1,...,t k in the in-private setting is atomic and con-sistent.

Proposition2Durability is preserved for transac-tions in the in-private setting.

We observe however that isolation is not pre-served by this set of rules.There are many isolation deficiencies for parallel execution.The following list is not exhaustive:

(LU):Transactions may read data from a location before another transaction uses this location,com-pute new values and write to the location after an-other transaction has written to this location.This behavior is called lost update.

(DR):A transaction may abort and may have writ-ten to a location.Another transaction may read data from this location before the state of the location is changed to the one before thefirst transaction has been performed.This behavior is called dirty read be-fore abort.The same problem occurs if a transaction writes several times to the location and another trans-action reads from this location between the writes. This situation is called dirty intermediate read. (DW).A transaction that is aborting later changes a location.The location is later(but before the abort of thefirst transaction)used by another transaction for computation of data which are written to another location or direct change of the same location.This behavior is called dirty write.

(NRR).A transaction may read several times from a location.The location has been changed by another transaction between the read operations of thefirst transaction.This behavior is called non-repeatable read.

(PR):A transaction inserts or deletes data to a loca-tion between the execution of aggregation functions in another transaction which predicates operate on the location of thefirst transaction.This behavior is called phantom read.

We observe that the transaction execution in the in-private setting does not have any dirty read or dirty write.

We shall demonstrate now that a number of refine-ments of the rule set above exists such that isolation can be reached:

Lock space solutions:We use the Lock(location) space or the ReadLock(location)and Write-Lock(location)spaces.

Let us consider the case of utilization of the Lock(location)space.The assignment of locks can follow different strategies:

Obtain all locks at the beginning:The transac-tion obtains all locks necessary during

initialization of the transaction.Two

settings are applicable:

Optimistic setting:Locks are only obtained

for write operations.The controller

causes an abort of the transaction or an

assignment of a wait state whenever an-

other transaction is competing for this

location.

Pessimistic setting:All locks are obtained

for all read and write operations.

Obtain locks just in time:Whenever a write op-eration(or in the pessimistic setting a read

operation)is performed by the transaction

the corresponding lock is obtained.

The release of the locks can be based on two strategies: