Operational semantics of transactions(2)

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

access and update the same database records.If this concurrency is uncontrolled,it may lead to problems such as an inconsistent database.”

TA as specific application programs(Lewis et al.2002):“A transaction is a program that can perform the following functions:

1.It can update a database to reflect the

occurrence of a real-world event that effects the state of the enterprise the database is modeling.

An example...

2.It can ensure that one or more real-world

events occur....

3.It can return information derived from the

database.”

The problems of the variety becomes worse if in the same source a variety of definitions is used.Beside the definition of(Hsu1998)in(Hsu/Kumar1998)an-other definition(H¨a rder/Reuter1998)is used which is repeated by most of the books in the database area (Vossen1991):

The concept of a transaction,which includes all database interactions between BeginOfTransaction and EndOfTransaction in the preceding example,re-quires that all of its actions be executed indivisibil-ity:Either all actions are properly reflected in the database or nothing has happened.No changes are reflected in the database if at any point in time before reaching the CT,the user enters the ERROR clause containing the RestoreTransaction.To achieve this kind of indivisibility,a transaction must have four properties:

Atomicity.It must be of all-or-nothing type described before,and the user must,whatever happens, know which state he or she is in. Consistency.A transaction reaching its normal end (EOT,end of transaction),thereby commit-ting its results,preserves the consistency of the database.In other words,each successful trans-action by definition commits only legal results.

This condition is necessary for the fourth prop-erty,durability.

Isolation.Events within a transaction must be hidden from other transactions running concurrently.If this were not the case,a transaction could not be reset to its beginning for the reasons sketched earlier.The techniques that achieve isolation are known as synchronization,and since Gray et al.

..there have been numerous contributions to this topic of database research..

Durability.Once a transaction has been completed and has committed its results to the database, the system must guarantee that these results survive any subsequent malfunctions.Since there is no sphere of control constituting a set of transactions,the database management system (DBMS)has no control beyond transaction boundaries.Therefore,the user must guarantee that things the system says have happened have actually happened.Since,by definition,each transaction is correct,the effects of an inevitable incorrect transaction(i.e.,the transaction con-taining faulty data)can only be removed using countertransactions.

Another requirement used is the serializability re-quirement:

Running two transactions in parallel should have the same effect as running them one after the other. Transaction order is important for the effect.Con-sider one transaction changing the value for x to2x and another transaction changing x to x−2.There-fore,order of execution matters.Execution of the sec-ond after thefirst gives2x−2.Execution of thefirst after the second gives2x−4.Therefore,serializabil-ity means that running a number of transactions in parallel should have the same effect as running them sequentially in a certain order.

These definitions are taught in database courses. Therefore,the database community defined in brief that a transaction is nothing else as a sequence of database operations that preserve the ACID properties.

1.2State Models Used in Transaction Defi-

nitions

There are very few papers and books proposing a state model of transaction execution.Let us summa-rize and extend the models proposed so far.We notice that the description below is not explicitly proposed in the literature but can be extracted on the basis of the intentional,narrative descriptions.

State model:The transaction engine hasfive states (Gray/Reuter1993):

BeginOfTransaction(BOT):The transactions marked by‘notfinalized’are in the BOT

state and wait for execution.

Run:The transaction engine runs the transac-tion and executes read,write and compute

statements.

Abort:The transaction is in an abort state.The resources occupied are freed.After com-

pletion the transaction returns to the BOT

state.

Commit:The transaction engine has completed the statements of the transaction and checks

now the correctness of the integrity con-

straints.If the constraints are valid the

next state is the EOT state.Otherwise,the

engine directs the transaction to the abort

state.

EndOfTransaction(EOT):The transaction en-gine completes the execution of the trans-

action and marks the transaction by‘final-

ized’.

This state model is displayed in Figure1.

r r

r r

r r j¨¨

¨¨

¨¨B

r r

r r

r r j

T

'

'

BOT

Run

Abort

Commit

EOT

Figure1:The States of a Transaction in the State Chart Approach

The model is often used in the literature in the form displayed in Figure1without the return from abort to BOT.However,transactions are rerun if they fail or abort.

Event model:The event model(Elmasri/Navathe 2000)is based on the events the recovery man-ager may use.

BeginOfTransaction:The label BOT marks the beginning of a transaction.

Read or Write:The transaction engine exe-cut …… 此处隐藏：3789字，全部文档内容请下载后查看。喜欢就下载吧 ……