the tmf application programming interface · transaction related issues, the interface is presented...

~TANDEM

The TMF ApplicationProgramming Interface

Program to Program Communication,Transactions, and Concurrency in theTandem NonStop System

Pat Helland

Technical Report 89.3February 1989Part Number 21680

THE TMF ApPLICATIONPROGRAMMING INTERFACE:

Program To Program Communication,Transactions, and Concurrency in the

Tandem NonStop System

Tandem Technical Report TR89.3Part Number 21680

Version 1.0

Copyright © 1989

Tandem Computers Incorporated

19333 Vallco ParkwayCupertino, CA 95014

Pat Helland2/15/89

~E OF CONTEmS

1. INTRODUCTION ...••.•...•.••.•......•.....•...•...••.•.••........•...•................. 1

2. REQUESTER SEMANTICS.....•...•......••.....•.........................•.......... 22.1. BeginTransaction / EndTransaction 22.2. AbortTransaction 32.3. WriteRead to a Server 32.4. NoWait WriteReads and Parallel Server Work 32.5. Matching Every Begin With an End or Abort 4

3. CONTEXT-FREE SERVER SEMANTICS ••••••••••••••••••••••••••••••••••••••••• 63.1. ReadUpdate $RECEIVE and Reply 63.2. WriteRead to a Server 73.3. AbortTransaction 73.4. Semantics of Reply 73.5. Context-Sensitive and Context-Free Servers in TMF 83.6. Serial Reuse for Different Transactions 8

4. UNILATERAL ABORT ON FAILURES•••••••••••••••••••••••••••••••••••••••••• 94. 1. Guarantees to Servers 94.2. WriteRead Behavior When Errors Occur 10

5. M ULTI·THREADING ....•..............•........•..•............................... 1 15.1. The Current Transaction 115.2. The TFile 115.3. Multi-Threaded Requesters 135.4. NoWait EndTransaction 135.5. The $RECEIVE Pseudo-File 145.6. Multi-Threaded Servers 145.7. Multi-Threaded Mixed Processes 15

6. WRITEREADS AND NIL CURRENT TRANSACTIONS ••••••••••••••••• 1 66.1. Reasons NOT to have a TransId 166.2. Setting the Current Transaction to NIL 176.3. Marking an OPEN to Not Send a TransId 17

7 . ASYNCHRONOUS ABORTTRANSACTION ••••••••••••••••••••••••••••••••••• 1 87.1. Work in Flight 18

8. NONSTOP AND TMF 2 08.1. Why Aren't There NonStop TMF Servers? 208.2. Checkpointing Strategy for Single-Threaded Requesters 218.3. Checkpointing Strategy for Multi-Threaded Requesters 238.4. Weird Things About Checkpointing 24

9. CONSISTENCY AND CONCURRENCY IN NONSTOP SQL••••••••••••••• 2 59.1. The Inconsistent Analysis Problem 269.2. The Uncommitted Dependency Problem 289.3. The Cascading Backouts Problem 309.4. NonStop SQL: Access Options and Degrees of Consistency 32

10. CONSISTENCY AND CONCURRENCY IN ENSCRIBE••••••••••••••••••••• 3 310.1. Enscribe: The Inserted Record Problem 3310.2. Enscribe: The Deleted Record Problem 3510.3. The EOF Anomaly 3610.4. Enscribe: Locking Modes 3710.5. Enscribe: Degrees of Consistency 38

11 . LOCKS AND LOCK RELEASE....••.....•............•............................ 3 911.1 Waited AbortTransaction11.2. Locks Held for BackOut11.3. Asynchronous Network Lock Release

394040

12. SUMMARY .••..•.•..•..••.....•................•........•...........•.................. 4 1

1 3 . ACKNOWLEDGEMENTS .....•.................•........•........................... 4 2

14. R EFERENCES.....••.................•..........•..•..............•..................... 4 2

Version 1.02/15/89

1. Introduction

TMF Application Programming InterfaceSection 1: Introduction

T M F is the name of Tandem's Transaction Monitoring Facility. TMFprovides protection and concurrency control for both Enscribe and NonStopSQL database files. Concurrency control is provided to allow manysimultaneous applications to access the database. Protection is provided for thedatabase against system failures, CPU failures, disc failures, and some classes ofapplication failures. TMF functions transparently In a distributedenvironment.

The TMF system provides a special view to the application. Eachinvocation of a server, database update, or call to a TMF procedure carries withit a set of implications. This document attempts to describe that view and theimportant implications of the user's interaction with TMF.

TMF is an integral part of the G U AR D I A N operating system. Theinterface presented to the application is the result of many components of thesystem. The on disc-process, the FileSystem, and Guardian itself all contributeheavily to the environment described here. It is impossible for theapplication programmer to distinguish between the contributions of thevarious components. Because the emphasis of this document is on thetransaction related issues, the interface is presented as the TMF AP PLI CAT IONPROGRAMMING INTERFACE.

TMF divides the application processes into two categories calledrequesters and servers. Are que s t e r is the process that invokesBEG I NT RAN SAC T ION and END T RAN SAC T ION. A s e r ve r is any otherapplication process that plays with the transaction. I will discuss the behaviorof these two types of processes separately.

Other topics discussed include transaction ABORTs when failures occur,multi-threading within a single GUARDIAN process, and program-to-programcommunication that mayor may not participate in a transaction. Specialattention is given to categorizing and expb.ining possible concurrencyproblems that an application program may experience.

Tandem Computers, Incorporated Page I

TMF Application Programming InterfaceSection 2: Requester Semantics

Version 1.02/15/89

2. Requester Semantics

The TMF requester is responsible for beginning and ending thetransaction and is the root of all of the work performed by the transaction. Itwill subcontract the work to various servers if it chooses. It is possible for aprocess to subcontract work to a server and not have the server's workparticipate in the transaction. This will be discussed in a later section.

The requester may cause parallel activity within a single transaction bysending NOW AIT requests to various servers. It is also possible for a singleprocess to function as a requester for many transactions.

Fig 1. BEGINTRANSACTIONand ENDTRANSACTION

Start of Process

I Database updates illegal~ Current Transaction

is NIL

BEGINTRANSACTION

I Database updates legal~ Current Transaction

is Non-NIL

ENDTRANSACTION

IDatabase updates illegal

~ Current Transactionis NIL

BEGINTRANSACTION

I Database updates legal~ Current Transaction

is Non-NIL

ENDTRANSACTION

IDatabase updates illegal

~ Current Transactionis NIL

Later, the requester invokes theprocedure ENDTRANSACTION. This againmakes its current transaction NIL.

The ENDTRANSACTION proceduredirects TMF to make all of the updates tothe database permanent. It signifies toTMF the completion of the transaction.

ENDTRANSACTION will cause theinvoking process to suspend (unless this isa multi-threaded requester discussedbelow) until TMF can ensure that thetransaction will remain permanent evenif the system fails.

Between the time that the application invokes ENDTRANSACTION and thetime the procedure completes, the application and the human beinginteracting with the transaction do not know whether the transaction hascommitted. This is the interval in which the requester is in doubt about theoutcome of the transaction.

2.1. BEGINTRANSACTION I ENDTRANSACTION

Every GUARDIAN process has anattribute associated with it called itscurrent transaction. The requesterprocess comes into existence with itscurrent transaction in a NIL state. If itattempts to update or lock an auditedcomponent of the database withoutinvoking BEGINTRANSACTION, an error( FEN 0 T RAN SID) is returned. Afterinvoking BEGINTRANSACTION, the requesterhas a non-NIL current transaction. Itmay then update TMF-protected data in thedatabase.

Once the ENDTRANSACTION procedure completes, the application isinformed whether or not the transaction has completed successfully.

Page 2 Tandem Computers, Incorporated

Version 1.02/15/89


2.2. ABORTTRANSACTION

At any time between BEGINTRANSACTION and ENDTRANSACTION, therequester may decide to abandon the transaction. It does this by invoking theprocedure ABORTTRANSACTION. 11J.e ABORTTRANSACTION procedure may beinvoked at ~y time by the requester even if it has issued requests to serverswhich may have work in progress for the transaction.

ABORTTRANSACTION is charged with the responsibility of undoing allchanges to the TMF-protected parts of the database. It is also necessary thatany subsequent work attempted for this transaction either be prevented fromoccurring or be undone shortly after occurring.

The ABORTTRANSACTION procedure will return to the caller immediately.The caller is allowed to continue even before the effects of the transaction areremoved from the system. Because locks are held on the TMF-protecteddatabase resources until after the changes are undone by BA C K 0 UT, therequester may attempt to access the database after the ABORTTRANSACTION and asubsequent BEGINTRANSACTION. In doing this, it is possible that the requesterwill wait for locks from the earlier transaction.

2.3. WRITEREAD to a Server

When a requester wants to subcontract some of the work of atransaction to a server, it uses the verb WRITEREAD 1. This normally will causethe requester to be suspended until the server completes the task requested ofit. The call to WRITEREAD will then complete with a response code that willindicate either successful or unsuccessful completion of the request.Normally, the work of the server will be part of the transaction started by themost recent BEGINTRANSACTION request. The server will automatically adoptthe transaction as its own during the processing of the request.

2.4. NOWAIT WRITEREADs and Parallel Server Work

When the requester issues the WRITEREAD to a server, it has the optionof performing a NOW AIT WRITEREAD. This form of WRITEREAD does not causethe requester to suspend,· but rather launches the request to the server andthen, without waiting for the server's work, allows the requester to continue.Later, the requester may use the A W A I T I 0 procedure to detect the answerfrom the server indicating the completion of the server's work.

When the requester continues work on the transaction in parallel withthe work of the server, it may launch new requests to other servers. There isno practical limit to the number of simultaneous requests that may be issued.

ENDTRANSACTION does, however, impose an obligation on the requesterwhen NOW AIT WRITEREADs have been used within the transaction beingended. The requester must ensure that it has received a RE PLY from everyserver before it calls ENDTRANSACTION. If there is still an outstanding requestwhen ENDTRANSACTION is called, an FETRANSNOW AITOUT (81) error will bereturned and the ENDTRANSACTION will have no effect.

The requester could also use the verb W R IT E . This is a subset of theWRITEREAD function which has the same TMF considerations as WRITEREAD.

Tandem Computers, Incorporated Page 3


Version 1.02/15/89

2.5. Matching Every BE GIN With an END or AB 0 R T

An important concept for the requester is that a BEGINTRANSACTION mustalways be paired with a matching ENDTRANSACTION or ABORTTRANSACTION. Thisis true even if the transaction is aborted by the system or by a server.

If a requester performs a BEGINTRANSACTION and is working away whensuddenly it receives an FE IN VT RAN SID error, it knows that somehow. thetransaction was aborted. This can occur because a server decided to ABORT thetransaction or because of a system fault. When this occurs, further attempts touse the transaction will continue to yield FEINVTRANSID. The requester has twochoices: it may invoke ENDTRANSACTION or it may invoke ABORTTRANSACTION.

A call to ENDTRANSACTION under these circumstances will surely returnan error and will not result in a committed transaction. This call will,however, provide the match to the BEGINTRANSACTION call. It also has the niceeffect of returning an error code that may possibly provide a hint about whatwent wrong. ENDTRANSACTION has the following possible results:

ERROR NAME LITERAL CAUSE OF ERRORFEOK 0 The transaction ENDED.FENoLCB 30 Couldn't allocate resources to perform

ENDTRANSACTION. The system is realsick and vour transaction is still alive.

FENOTRANSID 75 There is no current transaction.FEINVTRANSID 78 There is a current transaction, but this

process is a server for the transaction,not a reQuester.

FETRANSNOWAITOUT 81 Nowait I/O is still pending for thistransaction.

FETRANSABRTOWNERDIED 90 The transaction beginner process or aserver process working on thetransaction died.

FETRANSABRTNETDOWN 92 This transaction is distributed and anetwork connection to a system thatworked on this transaction has gonedown. The transaction was aborted tocooe with the failure.

FETRANSABRTAUDOVFL 93 This transaction has been abortedbecause it remained on the system forloneer than is convenient for TMF.

FETRANSABRTOPRCMD 94 The operator killed the transaction.FETRANSABRTDISCTKOVR 95 The transaction worked on a disc

process whose primary CPU just died.The transaction was aborted.

FEABORTEDTRANSID 97 This is a catchall error for a bunch ofsituations that can cause thetransaction to abort. Notable amongthese is a call to ABORTTRANSACTION.


Version 1.02/15/89


All of these error returns indicate a successful matching forBEGINTRANSACTION except for FENOLCB, FENOTRANSID, FEINVTRANSID, andFETRANSNOWAITOUT. If ENDTRANSACTION receives one of these errors, then youhave not successfully paired ENDTRANSACTION with BEGINTRANSACTION.

A call to AB 0 R T T RAN SAC T ION will also provide a match for theBEGINTRANSACTION. The ABORTTRANSACTION will simply return an error of FEO Kif the transaction is already ABORTED.

If a call to BEGINTRANSACTION is made (in a normal, simple requester)without first matching an earlier call with an EN D T RAN SAC T ION or anA BOR TTRAN SACTION, the second BEGINTRAN S ACTION will fail with anFETOOMANYTRANSBEGINS (Literal 83).


TMF Application Programming InterfaceSection 3: Context-Free Server Semantics

3. Context-Free Server Semantics

Version 1.02/15/89

A context-free server is a server that accepts a single message from arequester, performs a job, and issues a single reply message to respond to therequester. Once the reply message has been issued. the server has no state (orcontext) that may survive to be used in subsequent requests. A con t extsensi ti ve server is a one that engages in a multiple message dialogue withthe requester. In between messages, the context-sensitive server retains somestate information.

This section describes the view of life as seen by a context-free server.This is the only type of server that TMF understands. As we shall see. TMFdoesn't properly support the concept of a context-sensitive server.

The first topic will be the mechanisms which control a server'sparticipation in a transaction. Next. a discussion of the techniques a servermay use to subcontract some of the transaction's work to even more servers ispresented. The various options available to a server when errors occur arediscussed. Next, the semantics of the REPLY from a server and how that relatesto the transaction are discussed. Issues relating to context-free servers andtheir reuse in a way that maintains context are then presented. Finally, thissection addresses the serial reuse of context-free servers for differenttransactions ..

3.1. READUPDATE $RECEIVE and REPLY

A server first learns about an incoming request to work on atransaction by issuing a READUPDATE of SRECEIVEI. SRECEIVE is a pseudo-filewhich provides the generic mechanism by which a server process accepts anyincoming message. If the request was sent from a requester which wasworking on a transaction. it normally will carry with it the TRANS ID that labelsthe transaction. This is adopted by the server as its current transaction.

From the time that the server issues the READ UPDATE of SRECEIVE untilit issues the REPL Y verb, the single-threaded server will normally have thesame transaction as its current transaction. Any attempts to access or modify aTMF-protected resource will be done as a part of the current transaction.

In a fashion similar to BEGINTRANSACTION and ENDTRANSACTION, theREAD UPDATE of SRECEIVE is paired with a REPLY. For each incoming messageread from SRECEIVE, the server must issue a matching REPL Y.2

2

A server may also issue a READ of $RECEIVE which indicates that it does notintend to REPLY with data. This is not of great interest in this documentsince a READ of $RECEIVE will not adopt the transaction from the message.There are exceptions to this. SRECEIVE may be used to receive messagesfrom Guardian to describe system status information such as CPU-Down andCPU-Up messages. These .system-messages do not require REPLY.


Version 1.02/15/89

Requester

TMF Application Programming InterfaceSection 3: Context-Free Server Semantics

Server

Fig 2. A Message From Requester to Server.

3.2. WRITEREAD to a Server

A server process may also subcontract work to other server processes. Itdoes this just the same as a requester. The server simply issues a WRITEREAD tothe next server. The current transaction of the sending server is attached tothe request sent to the next server. .

Just as in a requester process. a server may choose to issue NO W A ITW RITEREADs to allow parallel work by invoked servers. The server must get allof its answers to NOW AIT WRITEREADs before issuing a REPLY or it will receivean FETRANSNOWAITOUT (81) error from the REPLY.

3.3. ABORTTRANSACTION

A server process is allowed to invoke ABORTTRANSACTION to abort itscurrent transaction. This allows a server that gets into a very big mess tocount on TMF to clean it up. If the server could not call ABORTTRANSACTION, itsonly recourse would be to return an error to the requester and hope that therequester would abort the transaction. Servers should be coded to invokeABORTTRANSACTION for requests that may have been partially performed.

When a server invokes ABORTTRANSACTION. it still has an obligation tocall REP!... Y. The call to ABORTTRANSACTION merely forces the transaction toabort. It does not affect the incoming request which still needs a REPLY.

The server is only allowed to call AB 0 RT T RAN SAC T ION between theREADUPDATE of SRECElVE and the REPLY. Once the REPLY has been issued, theserver loses the right to abort the transaction.

3.4. Semantics of RE PLY

When a server issues REPLY, it is indicating that it is through with therequest sent to it by the requester. Furthermore. the server is consenting tocommit the transaction (unless it has invoked ABORTTRANSACTION). The serverwill not be involved with the transaction again unless another request for thesame transaction arrives on SRECEIVE. Effectively, the server is voting yes tothe transaction's commitment. It will not be involved with the transaction'seventual ENDTRANSACTION. It will not be notified of the transaction's outcome.

Once the server has invoked REPL Y. it will have no current transaction.Any attempt to update or lock a TMF-protected resource yields an error. Thiswill persist until the process either RE A 0 U P D ATE s a new request fromSRECEIVE or (playing as a requester) invokes BEGINTRANSACTION. These arenormally the only ways to get a new current transaction.


TMF Application Programming InterfaceSection 3: Context-Free Seryer Semantics

Version 1.02/15/89

3.5. Context-Sensitive and Context-Free Servers in TMF

Some users of TMF have structured applications to have a multi-messagecommunication between a requester and a particular server process. Theserver process maintains context across the interval between the messages.This distinguishes context-sensitive servers from context-free servers. Ifdone properly, a' true context-sensitive server can be achieved. This can onlyhappen, however, if the server is willing to trust that the requester is neitherstupid nor malicious.

Suppose a requester and server want to perform a transaction thatconsists of five round-trip REQUEST-REPLY pairs. If less than all five of theseare performed, the transaction is not complete. Each time the server issues aREP L Y, it is informing TMF that, as far as the server is concerned, thetransaction may be committed. If the server has only performed three of thefive requests necessary to complete the transaction, this is amisrepresentation to TMF.

Now, if the requester is a nice (and properly coded) partner for theserver, it will ensure that the transaction aborts if anything prevents thecompletion of the entire transaction. This includes a mechanism to detect thedemise of the server in between requests followed by the restart of a newserver with the old server's name. Remember, the old server was maintainingCONTEXT across requests so the new server will not have the CONTEXT.

If an application is .very sophisticated, it can provide the support forcontext-sensitive servers that TMF is missing. It would be incorrect, however,to state that TMF has general support for context-sensitive servers.

3.6. Serial Reuse for Different Transactions

One thing at which TMF does excel is context-free servers. The normalway in which a server will function in TMF is by handling a single request fora transaction and then immediately moving on to the next transaction.

A context-sensitive server that only supports a single context at a timewould require that the server not begin work on the next transaction until therequester decides to commit or abort the current transaction and notifies theserver of this decision. The context-free server has no such constraint.Because the REPLY includes as a part of its semantics a complete separation ofthe server from the transaction, the server may immediately move on toanother transaction. This allows the server to be very highly utilized.


Version 1.02/15/89

TMF Application Programming InterfaceSection 4: Unilateral Abort on Failures

4. Unilateral Abort on Failures

TMF provides an important guarantee to servers: Even if the serverdoesn't trust the requester, the server's work will be entirely done or not doneat all. To . accomplish this, TMF must ensure the following things even in theface of a requester that deliberately tries to damage a server:

a) If the server application detects an application problem, itcan cause the transaction to be aborted.

b) The requester can't commit the transaction while theserver is in the middle of processing a single requestwhich may include a bunch of changes to its database.

c ) If the server application process or CPU fails in the middleof a set of changes to the server's database, the transactionwill abort.

If any of these guarantees is missing, the server's database could getmunched. These guarantees are enforced by a mechanism known asunilateral abort. This name arises from the server's ability to unilaterallydeclare that the transaction will abort.

This section describes the guarantees made to the server and someimplications that these guarantees have on the behavior of the WriteReadprocedure when errors occur.

4.1. Guarantees to Servers

Server processes are promised that until they issue RE PLY, thetransaction cannot commit. All changes that the server has made to thedatabase prior to the REPLY will participate in the transaction. Furthermore, ifthe server chooses to, it may invoke ABORTTRANSACTION and be sure that thetransaction will be undone.

Tandem Computers. Incorporated Page 9

TMF Application Programming InterfaceSection 4: Unilateral Abort on Failures

Version 1.02/15/89

4.2. W RITEREAO Behavior When Errors ·Occur

To provide the guarantees of unilateral abort, TMF transactions areautomatically aborted under some circumstances. This is performed by thesystem software when certain errors are received in response to messages.

Suppose a WRITEREAD to a server is issued and the server process diesbefore issuing the REPL Y. TMF must guarantee that the partially completechanges made by the server are undone. So, when the requester processreceives an FEPATHDOWN error from a WRITEREAD, the FileSystemautomatically aborts the transaction. The requester has no choice in thematter, otherwise the server would lose its guarantee.

The list of errors to WRITEREAD that will abort the transaction is:

ERROR NAME LITERAL CAUSE OF ERRORFETlMEOOUT 40 The

..for therequester gave up waiting

server. For all we know, the server wasupdating its database when the requestergave up and is not done. If we commit thetransaction, the server's database may getmunched.

FEPATHDOWN 201 The server process or CPU containing theorocess bit the dust.

FECPUFAIL 211 The CPU..

thecontaining server processdied in the midst of processing thereauest.

In addition to these, all errors between 240 and 255 (inclusive) willcause the transaction to be aborted. At present, the errors in this range are:

ERROR NAME LITERAL CAUSE OF ERRORFELHRETRY 240 Line Handler error -- didn't ~et started.FENETRETRY 241 Network error -- didn't llet started.FEBYPASSF AIL 246 FOX direct route failed -- aborted rea.FELHFAIL 248 Line Handler error -- aborted reQuest.FENETFAIL 249 Network error -- aborted reQuest.FENETDOWN 250 All paths to the system are dOWR.FENETPROTOCOLERROR 251 Network orotocol error.FENOEXPANDCLASS 252 Reauired Expand class not available.FETOOMANYUPS 255 Line Handler came uo too often.

In addition to errors received by WR ITER E AD, the transaction isautomatically aborted when a CANCEL is called on a WRITEREAD request to aserver, or when a CLOSE is called on the FILENUMBER of the open of the serverprocess while a request is outstanding. Both of these events cause therequester to stop waiting for the completion of the server.

Whenever the transaction is automatically aborted for one of thesereasons, the reason recorded for the abort is FETRANSABRTOWNERDIED.

Page 10 Tandem Computers. Incorporated

Version 1.02/15/89

5. Multi-Threading

TMF Application Programming InterfaceSection 5: Multi-Threading

Up until now, we have assumed that a process is only working on asingle transaction at a time. A requester calls BEGINTRANSACTION and worksexclusively on that transaction until it is time to call EN DT RAN SAC T ION.Similarly, a server READ UPDATEs a request from SRECEIVE and works only onthat request until it invokes REPL Y. Sometimes, this assumption is not true.

TMF supports the ability for requesters to juggle multiple simultaneoustransactions. Similarly, a dextrous server may be designed to handle a bunchof requests concurrently before it issues a REPLY. In fact, it is possible for aprocess to simultaneously be a requester for one transaction and a server foranother. It may even simultaneously fill both roles for the same transaction.

This section first introduces the concept of a current transaction andthen examines the TFILE and SRECEIVE mechanisms in depth. Following this,discussions are presented of multi-threaded requesters, multi-threadedservers, and multi-threaded processes that are both requesters and servers.

5.1. The Current Transaction

Each process has associated with it a current transaction. Thiscurrent transaction determines which transaction is associated with anydatabase work that the process may do. A WRITEREAD to a server will cause thework of the server to belong to the current transaction while it processes themessage. Similarly, the current transaction determines which transaction isaffected by an ENDTRANSACTION or ABORTTRANSACTION call.

The current transaction may be nil. This will happen, for example,immediately after a successful call to ENDTRANSACTION. When this occurs, thetransaction that used to be current is gone. Until explicit action is taken, notransaction will be current.

The current transaction may be one of the transactions begun by thisprocess or one of the transactions inherited from SRECEIVE when reading anincoming request.

5.2. The TFILE

The T FILE (short for Transaction FILE) keeps track of all transactionsbegun by this process which have not yet been explicitly ended or aborted. Itboth defines the maximum acceptable amount of multi-threading for atransaction requester and allows TMF to represent transactions in a fonn thatresembles a FILE.

Each entry in the TFILE contains both an identifier of the transactionand a status descriptor. The status value is used at the completion of thetransaction to record if the transaction has committed or aborted.

In its simplest fonn, the TFILE has only one entry (allowing at most oneconcurrent transaction). A simple call to BEGINTRANSACTION will automaticallycreate a TFILE with one entry. This mechanism allows a single-threadedrequester to ignore the existence of the TFILE.



Version 1.02/15/89

When a process wants to be a multi-threaded requester, it must OPEN theTFILE. The syntax for this overloads the OPEN procedure. It is:

CALL OPEN ("$TMP", filenumber, nowait-depth);

ept eanlne0 If the nowait-depth is zero, this is the same as if

BEGINTRANSACTION is called without first OPENing the TFILE.Calls to ENDTRANSACTION will be WAITED and only oneconcurrent active transaction will be allowed.

1 Only one concurrent active transaction will be allowed for theorocess. The call to ENDTRANSACTION will be NOW AlT.

2-255 There will be as many as nowait-depth concurrent activetransactions. ENDTRANSACTION will be NOW AlT.

The meaning of this call is that the process wishes to allow up tonowait-deplh concurrent active transactions. This is another way of saying,that the process will perform up to nowait-deplh BEGINTRANSACTIONs beforecalling ENDTRANSACTION.

The choice of STMP as the name of the device to open was motivated bythe fact that the name STMP was reserved and could never be used as a namethat has a different meaning to OPEN. In the OPEN procedure, a special checkis made to detect the string "STMP". OPENs of this form are treated specially asthe mechanism for defining the amount of TMF requester multi-threading.

The parameter now ail - d e p t h has two meanings. It controls thenumber' of concurrent active transactions and whether ENDTRANSACTION isWAITED or NOWAlT.

Nowait-depth is limited to values between 0 and 255. These are:

D h M

TFILECurrentTransaction

Tag(A) Transid: \X.3.27 <status> r+- ITag(B) Transid: \X.3.52 <status>Tag(C)Tag(D) Transid: \X.3.89 <status>Tag(E) Transid: \X.3.13 <status> ~Tag(F) Transid: \X.3.99 <status>Tag(G)Tag(H) Transid: \X.3.12 <status>Tag(l)

Fig 3. The TFILE and the Current Transaction


Version 1.02/15/89


Notice that the OPEN of the TFILE will return a filenumber. Thisfilenumber will be used in completing ENDTRANSACTION calls with AW AITI 0Uust like any nowait file completions). Using this filenumber, the user mayCLOSE the TFILE. This will abort any transactions that may be in progress.

If the application needs to alter the number of concurrent transactionsthat it may -begin, it must CLOSE and then re-OPEN the TFILE. This is not verypractical because it would cause all active transactions to abort.

5.3. Multi-Threaded Requesters

When BEGINTRANSACTION is invoked in a process that has opened theTFILE, the procedure call must supply a TAG parameter. The TAG value will becreated and returned by BEGINTRANSACTION and may be accepted as input bythe procedure RESUMETRANSACTION. The procedure AW AITIO will accept theTAG parameter and return a value for the TAG which matches a TAG previouslyreturned on a BEGINTRANSACTION.

When the multi-threaded requester calls BEGINTRANSACTION, the TAG forthe transaction is returned from the procedure call. In addi tion, the cur r e n tt ransac ti 0 n is altered to specify the new transaction. After the requesterhas begun a bunch of transactions, it will sometimes need to select a non-current transaction as the current one. This is accomplished by invoking:

CALL RESUMETRANSACTION (TAG);

The use of the TAG with BEGINTRANSACTION and RESUMETRANSACTIONallows the requester to switch between transactions.

5.4. NOWAIT ENDTRANSACTION

When a multi-threaded requester calls the procedure ENDTRANSACTION,it is asking to have the current transaction ended. TMF does not suspend therequester but rather allows it to continue working on its other transactionswhile the ENDTRANSACTION processing proceeds.

The multi-threaded requester is expected to use the procedure AWAIT I 0to recognize completions of ENDTRANSACTION as well as completions of otherfile requests. Enscribe database updates, WRITEREADs to servers, and other I/Oscan be issued as NO W AIT . requests that are issued on a .. file-open" basis. Therequests are described by their filenumber. AW AITIO always returns thefilenumber of ~e NOW AIT operation that just completed. In addition to thefilenumber, a TAG and a STATUS (e.g., PEOK) are returned by AWAITIO.

A multi-threaded requester issues I/Os on a file-by-file basis.W RITEREADs to servers are issued on the filenumber of the OPEN of the serverprocess. ENDTRANSACTIONs are implicitly associated with the FILE called theTFILE. Completions of a WRITEREAD are detected when AW AITIO reports an 1/0completion on the filenumber of the OPEN of the server. ENDTRANSACTIONcompletions are reported by AWAITIO as an I/O-completion on the filenumberof the TALE. The TFILE exists as a FILE to allow TMF to fit into the file-orientedmodel of the system.

If the requester has more than one ENDTRANSACTION in progress, it cantell which one has completed because AWAITIO returns the BEGINTRANSACTIONTAG for the transaction that ended.



Version 1.02/15/89

5.5. The $RECEIVE Pseudo-File

A server accepts incoming messages by OPENing and READUPDATEingthe $RECElVE. While $RECElVE is not really a file, it looks and acts much like afile. A server may open $RECEIVE with a receive-depth of 1 to 255. Areceive-depth greater than 1 signifies that the server is multi-threaded andintends to work on more than one concurrent request.

Each entry in $RECElVE corresponds to a request that has been read buthas not been the object of a REPLY. Each entry describes the request and itsREP LY. Associated with this information is the TR ANSID of the r eques t e r ' scurrent transaction when it issued the WRITER E AD. When the server isprocessing the request, this TRANSID defines the server's current transaction.

$RECEIVE CurrentTransaction

+ I\X.2.14\X.1.36\X.1.37\X.3.89

Transld:Transid:Transid:Transid:

ReceiveTag#1 RcvMsq #17 InfoReceiveTag#2 RcvMsg #45 InfoReceiveTag#3 RcvMsg # 2 InfoReceiveTag#4 RcvMsQ #16 InfoReceiveTag#5

~-~-..................~+~-~~"!""!""!~~~ReceiveTag#6 RcvMsa #20 Info Transid: \X.0.102

Fig. 4. $RECEIVE and the Current Transaction

When a multi-threaded server wants more work, it issues a NO W A ITREADUPDATE of $RECEIVE. When a request arrives, the READUPDATE'scompletion is detected via AW AIT 10. When this completion occurs, the serverreceives a $RECElVE TAG. This TAG serves to identify the request.

5.6. Multi-Threaded Servers

When a server performs a READUPDATE of $RECEIVE, this changes itscurrent transaction to' refer to the new arrival!. If the server wants to alterits current transaction to specify the TR ANSiD of one of the other requests. ituses the fdllowing invocation:

CALL ACTIVATERECEIVETRANSID (RECEIVET AG);

This will alter the current transaction to reference the one associatedwith the specified request. Note that there is no concept of a current requestin progress. The syntax for RE PLY accepts an explicit parameter for theR E C E I VET A G . It will not RE PLY to the request selected byACTIVATERECEIVETRANSID. So, it is not necessary for a server to make atransaction current to RE PL Y to the request from which it was received.

1 This is not true if the received message is a system message. In this case.the READUPDATE returns an FESYSMESS (6) warning with the incomingmessage. When this happens. the current transaction is unchanged.


Version 1.02/15/89


5.7. Multi-Threaded Mixed Processes

Notice that there is one current transaction. It may specify atransaction that was begun by this process or one that was adopted as a part ofaccepting a request. A process is not restricted to be exclusively a requester ora server. It may play both roles.

$RECEIVE

Specifies atransaction in eitherthe TFILE, $RECEIVE,or the nil transaction

CurrentTransactio n

+ I

\X.2.14\X.1.36\X.1.37\X.3.89

1ransid:Transid:Transid:Transid:

TFILETag(A) Transid: \X.3.27 <status>Tag(B) Transid: \X.3.52 <status>Tag(C)Tag(D) Transid: \X.3.89 <status>Tag(E) Transid: \X.3.13 <status>Tag(F) Transid: \X.3.99 <status>Tag(G)Tag(H) Transid: \X.3.12 <status>Tag(l)

ReceiveTag#1 RcvMsa #17 InfoReceiveTag#2 RcvMsa #45 InfoReceiveTag#3 RcvMsg # 2 InfoReceiveTag#4 RcvMsg #16 Info

ReceiveTag#5~~~_~~~~_~~~~~~ReceiveTag#6 RcvMsa #20 Info Transid: \X.0.102

Fig 5. The TFILE, $RECEIVE and Current Transaction all playingnicely together.

When a process is a hybrid requester and server, it still uses the sameprocedures to switch amongst the transactions as the requester and server.The RESUMETRANSACTION procedure is used to select a transaction in the TFILEas the current transaction. The ACTIV ATERECEIVETRANSID is used to select atransaction in $RECEIVE as the current transaction.

Note that a single process may function as both a requester and serverfor the same transaction. Suppose process A begins a transaction and does aWRITEREAD to process B. If process B then does a WRITEREAD back to process A,the transaction may arrive back at process A in $RECEIVE. If this were tooccur, the server component of the process must REPL Y before the requestercomponent could END the transaction.


TMF Application Programming InterfaceSection 6: WRITEREADS and NIL Current Transactions

Version 1.02/15/89

6 • W RITEREADs and NIL Current Transactions

Under most circumstances. it is wonderful to have a non-NIL currenttransaction. If the application tries to update or lock a file and the file is aTMF-audited file. .the current transaction must not be NIL or an error willresult. If the files are not TMF-audited. it will not matter if the currenttransaction is NIL or non-NIL.

There are times. however. when it is imponant to have a NIL currenttransaction. When performing a WRITEREAD to a server. a requester may wishto decide that the server should not share in a transaction with the requester.To make this happen. the requester must ensure that its current transaction isNIL when the WRITEREAD to the server is issued.

This section discusses the reasons why a requester may wish to avoidsharing the transaction with the server and the techniques that it may employto ensure that no transaction is shared.

6.1. Reasons NOT to have a TRANSID

There are two basic reasons why a requester would not want to share atransaction: performance. and separation of function.

First. let's discuss performance. This is really only an issue when therequest is going to be transmitted across the network. If both the requesterand server are located on the same system. there are no performance reasonsto avoid sharing the transaction.

On the other hand. if the requester and server are located on differentnodes. the act of sharing the transaction with the server on the other nodecauses TMF to treat the two systems as panicipating in a full-blown networktransaction. This will cause additional TMF overhead. If the server is notgoing to update or lock any TMF-audited files as a pan of the requester'stransaction. it seems silly to accrue the overhead of a network transaction.Some sophisticated applications will explicitly avoid sharing transactions witnthe server to avoid this overhead.

The other reason to avoid sharing transactions is to provide a separationof function. The requester may realize that the server is going to perform atask that logically belongs in a separate atomic transaction. The failure of therequester's transaction should not automatically cause the failure of theserver's. and vice-versa.

Sometimes the requester simply wishes to be resilient to failures ortime-outs of the server. For example. suppose the application wishes to send amessage to the spooler. The spooler does not utilize any TMF-audited databasefiles. Its behavior is unaltered if the transaction is shared or not shared.

If, however, the request to the spooler occasionally times-out, this wouldcause the requester's transaction to abort if it is shared. By setting the currenttransaction to NIL before issuing the WRITEREAD to the spooler, the requester'stransaction will not abort if a time-out on the WRITEREAD occurs.


Version 1.02/15/89

TMF Application Programming InterfaceSection 6: WRlTEREADS and NIL Current Transactions

6.2. Setting the Current Transaction to NIL

A number of techniques exist to ensure that the current transaction isNIL. So far, we have discussed:

ENDTRANSACTION

ABORTTRANSACTION

REPLY

Restart the process

Once this is executed, the currenttransaction is NIL.

This also zaps the current transaction.

If you RE PLY to the request whichbrought the current transaction to theserver, RE PLY leaves the processwithout a current transaction.

If you have never called BEGIN orREAD U PO ATE from $RECEIVE, thecurrent transaction will be NIL.

Each of these techniques has side effects. For this reason, I recommendthe use of:

CALL RESUMETRANSACTION (OD);

The TAG 0 D is magic and is guaranteed to be different from anylegitimate BEGINTRANSACTION TAG. It will always cause the current transactionto be set to NIL.

Notice that this is somewhat weird in a server. The server will alwaysuse ACTIVATERECEIVETRANSID to switch to a non-NIL current transaction.When switching to a NIL current transaction, the RE SUM ET RAN SAC T IONprocedure must be used. C'est la vie!

6.3. Marking an OPEN to Not Send a TRANSID

There is one other way to ensure that the message to a server is notblessed with a TRANSID. This is done by marking the OPEN of the server in away that indicates that none of the messages to the server will get a TRANSIDeven if the current transaction is not nil.

To mark the OPEN as not playing the transaction game, a SET MOD E IS

invoked. The SetMode value is (117) and it is called SMAIPCNOTRANSID.


TMF Application Programming InterfaceSection 7: Asynchronous ABOR'I'TRANsACTION

7 . Asynchronous ABORTTRANSACTION

Version 1.02/15/89

This section discusses some of the special issues of ABORTTRANSACTION.There are many circumstances under which a transaction may be aborted.Some of these can cause the application to see unusual behavior from thesystem.

7.1. Work in Flight

Transactions may be aborted due to CPU failure, network line failures,failures of the remote system in a network transaction, operator command, oran application process failure. There is even a system mechanism toautomatically abort a transaction that has simply lived too long. At any timeduring the processing of a transaction, the transaction may be aborted. Theapplication must be prepared to deal with this.

When a transaction gets aborted while the application is working on it,the application will simply start receiving errors as it tries to do things. Anyattempts to lock or update the database or to distribute the transaction to theremote server will result in an error. At first, the errors may be one of theclass of errors that describe a reason for aborting a transaction. These include:

ERROR NAME LITERAL CAUSE OF ERRORFETRANSABRTOWNERDIED 90 The transaction beginner process

croaked.FETRANSABRTNETDO WN 92 This transaction is distributed and a

network connection to a system thatworked on this transaction has gonedown. The transaction wasautomatically aborted to cope with thefailure.

FETRANSABRTAUDOVFL 93 This transaction has been abortedbecause it remained on the system forlonller than is convenient for TMF.

FETRANSABRTOPRCMD 94 The operator blew away thetransaction.

FETRANSABRTD~CTKOVR 95 The transaction worked on a discprocess whose primary CPU just died.This causes the transaction to beaborted.

FEABORTEDTRANSID 97 This is a catchall error for a bunch ofsituations that can cause thetransaction to abort. Notable amongthese is a call to ABORTTRANSACTION.


Version 1.02/15/89

TMF Application Programming InterfaceSection 7: Asynchronous ABORTTRANSACTION

Eventually, the transaction is completely aboned and the system nolonger views it as an aboning transaction. This occurs even if the applicationhasn't stopped attempting to use the transaction. If the transaction getscompletely aboned and the application continues to try to use the transaction,it will stan to receive FEIN VT RAN S ID (error 78). This error will persist aslong as the. application attempts to use the transaction.

Notice that there is a race happening here. The error received by theapplication is dependent on the promptness with which the application tries touse the transaction. The application may never see the error describing whythe transaction aboned. This depends on tipting.

The only accurate record of the error code provided to the application iskept in the TFILE of the transaction's beginner. This is retained until thebeginner matches the BEGINTRANSACTION by issuing an ENDTRANSACTION orABORTTRANSACTION command. If an ABORTTRANSACTION is issued, the error codedescribing why the transaction aborted will be discarded. If anENDTRANSACTION procedure is issued, the error code will be returned. Noticethat the ENDTRANSACTION call still had the effect of providing the match to theBEGINTRANSACTION, even though an error was returned.


TMF Application Programming InterfaceSection 9: Locks and Lock Release

8. NonStop and TMF

Version 1.02/15/89

TMF includes some basic functions to support the implementation of.NonStop Requesters. It does not support the concept of NonStop Servers.

The most notable NonStop user of TMF is the Pathway TCP process. ThePathway TCP is a NonStop Multi-Threaded Requester which provides automaticNonStop execution to Pathway users. It performs checkpointing to the backupTCP to ensure NonStop.

This section first discusses why TMF has no concept of a NonStop Server.Next, an overview of the strategy that should be taken to implement a SingleThreaded NonStop TMF Requester is presented. Finally, a discussion of theconsiderations required for Multi-Threaded Requesters is presented.

8.1. Why Aren't There NonStop TMF Servers?

NonStop for applications is considered to be built "on-top" of TMF. Thatis. a CPU failure may cause transactions to abort. TMF provides anenvironment where an application can resume from a clean transactionboundary. It does this by aborting any transactions that might not becomplete. The NonStop Requester mechanisms simply allow the application toaccurately decide which transactions were aborted by TMF and must berestarted.

Notice that TMF Servers only function as a part of a transaction. Inbetween transactions, servers must be context-free 1. Because TMF will resetthe database to a transaction boundary in the event of a failure. a server mustalso reset its state back to a transaction boundary in the event of a failure. If aserver process fails, it either must have completed its work or the partial workwill be discarded.

In the event of the loss of a server, we do not need to have a backupserver which contains any context. We simply need new servers which haveno context to start fresh on new transactions. This implies that servers neverneed to checkpoint any information describing the state of transactions. Forthis reason, TMF does not support any mechanisms for NonStop Servers.

To assist the application in keeping servers available in the face of CPUfailures. Pathway supports the concept of server classes. Each server classconsists of one or more instances of a particular type of context-free server.If some of these processes fail due to the death of a CPU. Pathway willautomatically restart them as needed.

See section 3.


Version 1.02/15/89


8.2. Check pointing Strategy for Single-Threaded Requesters

A NonStop Requester consists of two processes, a primary and a backup.Each of these two processes has a TFILE. Let's first examine the TFILE of asingle-threaded NonStop requester.

Terminal 1/0•

Checkpoint (including TFILE) [A]BEGINTRANSACTION

••

------...... Failure (1)SEND TO SERVER

•••

Checkpoint (including TFILE) [B]

-------... Failure (2)ENDTRANSACTION-------.... Failure (3)

Fig 6. Checkpoints in a Single-ThreadedNonStop Requester

Please note that Fig 6 is directly stolen from a paperwritten in 1982 by Tony Lemberger[Lem b8 2]. Tony's paperexplores TMF and checkpointing in greater depth than thisdocument.



Version 1.02/15/89

The basic strategy is to count on TMF to commit or abort eachtransaction completely. We then only need to count on the backup requesterto redo a transaction if and only if it was aborted by TMF. This will ensure thatthe transaction is performed exactly once.

Please examine figure 6. Notice that two calls to CHECKPOINT are placedin the loop for' each transaction. Let's first examine the function ofCHECKPOINT-B. When CHECKPOINT-B sends the state of the TFILE to the BACKUP,TMF becomes aware of the fact that the backup is involved with the'transaction. When the transaction is committed or aborted, not only does theprimary's TFILE get updated to remember the outcome of the transaction, thebackup's TFILE also gets updated.

Because TMF updates the TFILE in the backup, the backup requester candifferentiate between FAILURE-2 and FAILURE-3. If the backup notices a failureof the primary after receiving CHECKPOINT-B, it must call the procedureRESUMETRANSACTION. If the problem occurred at FAILURE-2, theRESUMETRANSACTION will return one of the FEABRTXXXX errors listed above inSection 7. If, on the other hand, the problem occurred at FA I LUR E-3, theRESUMETRANSACTION will return an FEENDEDTRANSID.

So. if RESUMETRANSACTION returns FEABRTXXXX, the transaction should berestarted. If it returns FEENDEDTRANSID, it should not be restarted.

Notice that the backup requester may need to performRESUMETRANSACTION. This requires knowledge of the BEGINTRANSACTION TAG.This means the primary requester must call BEGINTRANSACTION to get the TAG.

Next. let's examine CHECKPOINT-A. Its most important function will be toensure that the backup requester has enough information to restart thetransaction should the primary die. In addition. CHECKPOINT-A must clean outthe TFILE of the transaction that was ENDED in the last trip around the loop.

When the CHECKPOINT procedure is called, it will carry informationdescribing the current transaction. If the last thing that happened to thecurrent transaction was that it ended or aborted. we really have a NILtransaction. The TFILE has a special mechanism that lets it remember andcheckpoint that the transaction has completed. The backup requester willthen mark its TFILE entry as available. Without CHECKPOINT-A to mark thebackup's TFILE as empty. the backup's TFILE would overflow and furthercheckpoints would not work.

Finally. let's examine FAILURE-!. If the primary dies at FAILURE-I, thebackup has received CHECKPOINT-A but not CHECKPOINT-B. Because the backuphas not received CHECKPOINT-B. it is not possible that the primary calledENDTRANSACTION. Any transaction started by the primary will be undone byTMF. The backup should restart from the state checkpointed by CHECKPOINT-A.


Version 1.02/15/89


8.3. Checkpointing Strategy for Multi-Threaded Requesters

To understand the special considerations for Multi-Threaded Requesters,it is imponant to first understand the behavior of the procedure CHECKPOINT.

When CHECKPOINT is called with a list of files and one of them is theT F ILE, it will gather infonnation about a single transaction and send it to thebackup requester. The transaction that gets checkpointed is the cur r en ttransaction (well, almost... more on this in a second).

To ensure that the correct transaction is current, each thread mustremember the most recent BEGINTRANSACTION TAG that it used. This TAG shouldbe supplied to RESUMETRANSACTION before calling CHECKPOINT.

Terminal I/O•

RESUMETRANSACTION (TAG n-1)Checkpoint (including TFILE) [A]BEGINTRANSACTION

••

--------.. Failure (1)SEND TO SERVER

•••

RESUMETRANSACTION (TAG n)Checkpoint (including TFILE) [B]

-------.... Failure (2)ENDTRANSACTION

--------•• Failure (3)

Fig 7. Checkpoints in a Multi-ThreadedNonStop Requester



Version 1.02/15/89

Please examine Figure 7. Notice that the RE SUM E T RAN SAC T IONimmediately before CHECKPOINT-A must utilize the TAG associated with theprevious BEGINTRANSACTION. That transaction is now long gone having ENDEDduring the last iteration of the loop. It is imperative that this completedtransaction be the target of the RESUMETRANSACTION so that CHECKPOINT-A cancause the entry in .the backup's TFILE to be emptied.

8.4. Weird Things About Checkpointing

There are two weird things about checkpointing and the TFILE. The firstis that the transaction checkpointed is not really the current transaction. Forthe sake of discussion, let's call it the trans-to-be-checkpointed.

The current transaction may be altered by: BEGINTRANSACTION,ENDTRANSACTION, ABORTTRANSACTION, READUPDATE from SRECEIVE, REPLY,RESUMETRANSACTION, and ACTIVATERECEIVETRANSID. The trans-to-bee h e e k poi n ted can only be altered by: BE GIN T RAN SAC T ION andRESUMETRANSACTION. This means that the trans-to-be-checkpointed may bedifferent than the current transaction. This is weird.

Furthermore, RESUMETRANSACTION can work for a transaction that hasalready ENDED or ABORTED. If the TAG of the completed transaction is supplied,RESUMETRANSACTION will return an error (either FEENDEDTRANSID orFE A B RT XX X X). Even though an error was returned, the current transaction willbe set to nil and the trans-to-be-checkpointed will be set to the charredremnant of the completed transaction. This. also, is weird.


Version 1.02/15/89

TMF Application Programming InterfaceSection 9: Consistency and Concurrency in SQL

the database.they can seeOccasionally,

9. Consistency and Concurrency in NonStop SQL

TMF allows multiple transactions to concurrently accessSometimes, as various transactions acce~s and update the database,the effects· of other concurrent and incomplete transactions.these interactions can produce undesirable results.

Users of SQL are able to automatically ensure that concurrenttransactions do not interfere with their transaction. This is done by using theREPEATABLE ACCESS option on the transaction's SQL statements. REPEATABLEA CCE S S is said to provide degree three consistency. A transaction usingREPEATABLE ACCESS cannot be affected by concurrent transactions.

Eswaran, Gray, Lorie, and Traiger introduced the notion ofconsistency in 1974 [Eswa741, They describe the concept that the databasehad a set of assertions about the data. An example of an assertion about thedata in a bank's database may be that the sum of the account balances for aparticular branch must equal the branch total balance. The database is said tobe consistent if it satisfies all of these assertions.

In 1976, Gray, Lorie, Putzolu, and Traiger defined four degrees ofconsistency [G ray7 6]. These four degrees of consistency define a hierarchyof increasing isolation from concurrent transactions. As the degree increases,the number of problems from interacting transactions is reduced.

Degree 0 consistency is the most basic and we do not consider it here.The three remaining degrees of consistency (1, 2, and 3) can best be explainedby showing the problems that they solve!. This table matches theconcurrency problems to the degree of consistency that fixes the problem:

Concurrency Degree of Consistency SQL Access Mode toProblem That Fixes the Problem Get Consistency

Inconsistent Analysis De2ree 3 Consistencv REPEATABLE ACCESSUncommitted Deoendency DeJ!:ree 2 Consistency STABLE ACCESS

CascadinJ!: Backouts De2ree 1 Consistency BROWSE ACCESS

This section first describes the three problems listed above. Thischaracterizes these degrees of consistency. Then, a summary of the accessoptions available in NonStop SQL, the locking actions implied by these accessoptions, and the resulting degrees of consistency is presented.

See [Date84] Chapter 11 for a beautiful discussion of these issues as theyrelate to IBM's DB2 product. This problem oriented presentation ismotivated by that discussion.



Version 1.02/15/89

Before: Account X Deposits Loans$50 $120 $90

Transaction A: Withdrawal :Iima Transaction B: Loan

- -READ Account X ($50) t1 -

- I -- t2 READ Deposits ($120)

- I -READ Loans ($90) t3 -

- I -- t4 READ Loans ($90)

- I -READ Deposits ($120) t5 -

- I -- t6 WRITE Loans ($115)

- I -WRITE Deposits ($95) t7 -

- I -WRITE Account X ($25) t8 -

+After: Account X Deposits Loans

$25 $95 $115

Fig 8. The Inconsistent Analysis Problem

"A withdrawal or loanmay only be performedif the total depositsremains greater than oreoual to the total loans"

This is anexample of anassertion about thedata as described in[Eswa74]. To enforcethis assertion. bothtransactions operatingon the bank's datacheck that theassertion will remainintact before theyperform their work.

Please examinethe two transactions inFigure 9. Each of thesetransactions hasspecial provisions toensure that theassertion about loansand deposits isenforced. It is easy tosee how an application programmer would assume that the policy wouldremain intact.

9.1. The Inconsistent Analysis Problem

The Inconsistent Analysis Problem is illustrated by Figures 8 and 9.

Suppose wehave a bank whichenforces the followingpolicy:

Transaction A: Transaction B;Withdraw Y dollars from Account X; Loan Z dollars;

READ Account X READ DepositsIf Y > X then Abort READ LoansREAD Loans If Deposits < Loans + Z then AbortREAD Deposits WRITE Loans :,.. Loans + Z;If Deposits - Y < Loans then Abort Give Customer Z dollars.WRITE Deposits ;= Deposits - Y;WRITE Account X ;= Account X - Y;Give Customer Y dollars.

FiQ 9: Transactions for Inconsistent Analysis Problem


Version 1.02/15/89


Now, please examine Figure 8. In this example, an attempt is made towithdraw $25 frl'm account X at the same time that another transaction isattempting to loan $25. As these two transactions execute concurrently, eachtransaction attempts to enforce the policy that loans shall not exceed deposits.Neither transaction is erroneous. A problem arises, however with theconcurrent ~xecution of the two transactions that leads to the policy about thedata being violated. Please examine the AFTER state of the data in Figure 8.

This problem arises because the database manager did not enforce a lockprotocol that provides degree three consistency[Gray76].

A transaction T is said to see degree three consistency if:

( a) T does not overwrite uncommitted data of other transactions.

( b) T does not commit any writes until it completes all of its writes(Le. it doesn't release any locks on written records until thetransaction commits).

( c ) T does not read uncommitted data from other transactions.

( d ) Other transactions do not write on data read by T before Tcommits or aborts.

To enforce this level of consistency, the transaction must follow a set oflocking rules called the degree three lock protocol [Gray76]

The degree three locking protocol requires:

( a) T sets an exclusive lock on any data that it writes.This lock must be held until T commits or aborts.

( b) T sets a share lock on any data that it reads.This lock must be held until T commits or aborts.

Again, please examine Figure 8. If the two transactions had observed adegree three lock protocol, then:

( a) Transactions A and B would both have held share locks on theDeposits and Loans records.

(b) Transaction B could not have written the Loans record at time t6.It would have had a lock conflict with Transaction A's share lock.

( c ) Transaction A could not have written the Deposits record at timet7. It would have had a lock conflict with Transaction B's sharelock.

It is imponant to remember that degree three consistency completelyisolates the transaction from inconsistencies due to concurrency.

Another name for degree three consistency is repeatable access.This name is due to the propeny of degree three consistency where anythingread by a transaction remains unchanged until the transaction completes.From the transaction's perspective, it may repeatedly access its data withoutseeing any difference.



Version 1.02/15/89

Along comestransaction B to tryto loan $40. Transaction B examinesthe Deposits recordand sees $145 dollars.Based on thisinformation, trans-action B loans the$40 and commits(ENDTRANSACTION)at time t7.

Then, at timet8. transaction C isaborted. This re-turns the originalvalue ($120) to theDeposits record.

At the end ofthis execution, theLoans record contains a value largerthan the Depositsrecord. This violatesthe policy.

attempting to deposit $25 into

account X. It updatesthe Deposits record tocontain $145 attime t3.

Before: Account X Deposits Loans$50 $120 $90

Transactjon C: peposit :nma-

READ Account X ($50) t1

- IREAD Deposits ($120) 12

- IWRITE Deposits ($145) t3 Transaction B: Loan

- I- t4 READ Deposits ($145)

- I -- t5 READ Loans ($90)

- I -- t6 WRITE Loans ($130)

- I -- t7 ENDTRMf.C3ACllON

- IBAO<OUT t8

+After: Accoynt X Deposits Loans

$50 $120 $130

Fig 11. The Uncommitted DependencyProblem

9.2. The Uncommitted Dependency Problem

The Uncommitted Dependency Problem is shown by Figures 10 and 11.This example takes place at the same bank as the example for the InconsistentAnalysis Problem. Please review the Transaction B (the loan transaction) inFigure 9.

Figure 10 documents another Transactjon c:transaction at the bank. This one Deposit Ydollars into Account X:(transaction C) accepts a deposit and READ Acx:ount Xcredits the customers account and the READ DepositsDeposits record. accept Y dollars from customer

This example of the Uncommitted WRITE Deposits :=- Deposits + Y;Dependency Problem occurs as an I-_W;";;,,:,,R;.;,IT.;.;E=-:.A:::cco::::.;u~n.:.:t..;.X~:=-;.:A..;;c~c;,;:o;.;:u;,;,;n.;.tX;";,,,,;+_Y~'-4

interaction between transaction B and Fig 10: The Deposittransaction C. The problem arises iftransaction B can see the changes of .... T..r._a..n...s_a..c.t..io....n_. ...transaction C before they are committed.

Please examine Figure 11. Transaction C is


Version 1.02/15/89


The uncommitted dependency problem arises becausemanager did not enforce a lock protocol that providesconsistency [Gray761.

A transaction T is said to see degree two consistency if:

the databasedegree two

( a)' T does not overwrite uncommitted data of other transactions.

( b) T does not commit any writes until it completes all of its writes(i.e. it doesn't release any locks on written records until thetransaction commits).

( c ) T does not read uncommitted data from other transactions.

Notice that this is the exact same list as the list for degree threeconsistency except that degree three consistency adds restriction (d). Degreethree consistency is always as strict or stricter than degree two consistency.

Notice, also, that it is restriction (c) that will eliminate the uncommitteddependency problem.

To enforce this level of consistency, the transaction must follow a set oflocking rules called the degree two lock protocol [Gray761

The degree two locking protocol requires:

( a ) T sets an exclusive lock on any data that it writes.This lock must be held until T commits or aborts.

( b) T sets a share lock on any data that it reads.This lock may be released once the data item has been read.It does not have to be held until the transaction completes.

Again, please examine Figure 11. If a degree two lock protocol had beenin effect, the attempt by transaction B to read the Deposits record at time t4would have been denied. Transaction B would not see the erroneous value forthe Deposits and would not have granted the Loan. This would have made thebank happier and the borrower less happy.



Version 1.02/15/89

Transaction D IiIIul Transaction E

- -READ R (10) t1 -

- I -WRITE R (20) t2 -

- I -t3 READ R (20)- I- -t4 WRITE R (30)- I- -t5 ENDTRANSACTION- I-

BACKCXJT t6

'~

After: Record A10

Fig 12. The Cascading Backouts Problem

9.3. The Cascading Backouts Problem

The Cascading Backouts Problem is shown by Figure 12. Suppose twotransactions both intend to read and write record R. Transaction 0 readsrecord R at time t1 and writes a "20" to it at time t2.

Then, along comestransaction E. It readsrecord R at time t3 andwrites the value "30" intorecord R at time t4.Transaction E now commitsby invoking ENDTRANSACfION at time 15.

At time t6, transaction 0 gets aborted andBACKOUT runs. This leads toa severe problem. WhenBACKOUT runs against thework of transaction 0, itwill restore the beforeimage of record R to thestate it was in before timet2. This places the value 10into record R. When thishappens. the change torecord R that was made attime t4 is destroyed. Tomake transaction E atomic, it must be undone also. It is said that the backout oftransaction 0 causes the cascading backout of transaction E.

It is very difficult for either a system or an application programmer todeal with Cascading Backout. The system must retain knowledge describingwhich transactions have depended on information from other transactions sothey can be aborted. The application programmer doesn't have anyreasonable way of knowing when a transaction is permanent and no longersubject to a cascaded backout. For these reasons. this problem is preventedfrom ever occurring in TMF.


Version 1.02/15/89


The cascading backouts problem can be prevented by enforcing a lockprotocol that provides degree one consistency[Gray? 6].

A transaction T is said to see degree one consistency if:

( a ) T does not overwrite uncommitted data of other transactions.

( b) T does not commit any writes until it completes all of its writes(i.e. it doesn't release any locks on written records until thetransaction commits).

Notice that these rules are part of the list for degree two and degreethree consistency. Degree three consistency is always as strict or stricter thandegree two consistency. Degree two consistency is always as strict or stricterthan degree one consistency.

To enforce this level of consistency, the transaction must follow a set oflocking rules called the degree one lock protocol[Gray76]

The degree one locking protocol requires:

( a ) T sets an exclusive lock on any data that it writes.This lock must be held until T commits or aborts.

( b) T may read anvthina it wants without settina locks.

Again, please examine Figure 12. If a degree one lock protocol had beenin effect, transaction D would have held a lock on record R starting at time t2.This would have prevented transaction E from writing record R at time t4(since we are discussing degree one consistency, the read of R at time t3 wouldhave succeeded). Because the write of record R by transaction E wasprevented, the BACKOUT of transaction D has no direct effect on any recordswritten by transaction E.



Version 1.02/15/89

DiscusSIonAccess Ophon

9.4. NonStop SQL: Access Options and Degrees of Consistency

NonStop SQL allows a programmer to write a transaction that completelyachieves either degree one, degree two, or degree three consistency.

To accomplish a particular degree of consistency for a transaction,several access options are available. Each of these access options applies toan individual SQL statement. This access option gives that statement its degreeof consistency. A transaction will have a degree of consistency matching the·lowest degree of consistency of the SQL statements in the transaction.

The access options and their degrees of consistency are:

Degree ofConslStencv

REPEATABLE ACCESS Degree Three In REPEATABLE ACCESS. everything read by the transactionwill have at least a share lockpreventing its modification.These locks will be releasedwhen the transaction ends.

STABLE ACCESS Degree Two Using STABLE ACCESS. everything examined will have atleast a momentary share lockobtained. This prevents anyviewing of uncommitted data.The share locks on the data arenot guaranteed to be kept untilthe end of the transaction.

BROWSE ACCESS Degree One

STABLE ACCESS is the default.This is a trade-off between thegreater consistency of RE PEATABLE A CCESS and the greaterconcurrency of STABLE ACCESS.Using Browse Access, thetransaction may look throughlocks and see uncommitted data.This provides very highconcurrency for transactionsthat do not do updates. Theresults of the transaction areDotentiallv based on bogus data.

These options may be issued on any SELECf. INSERT. UPDATE, or DELETEstatement. (The BROWSE ACCESS option may only be used on a SELECT). Theonly important issue to remember is that the transaction's degree ofconsistency will be the lowest of its constituent statement's degrees. Forexample, you could make a fuzzy copy of table T2 and call it Tl with:

INSERT INTO Tl SELECf ,.. FROM T2 FOR BROWSE ACCESS;

If you wanted an exact copy of table T2, you would use:

INSERT INTO Tl SELECT ,.. FROM T2 FOR REPEATABLE ACCESS;


Version 1.02/15/89

TMF Application Programming InterfaceSection 10: Consistency and Concurrency in Enscribe

10. Consistency and Concurrency in Enscribe

Unlike NonStop SQL, users of Enscribe do not have an easy means ofexpressing their desired trade-off between consistency and concurrency. Thisoccurs for two fundamental reasons:

• Enscribe has no explicit concept comparable to NonStop SQL'saccess mode. There are rules that may be followed in theapplication that will approximate the various degrees ofconsistency. These rules must be manually enforced by theprogrammer and are not automatic like NonStop SQL.

• There are some problems and anomalies with Enscribe's lockingthat prevent a clean and concise implementation of the variousdegrees of consistency.

Section 10 documents the relationship between Enscribe's behavior anddegree 1, 2, and 3 consistency. This is presented in five sections. First, an

. Enscribe problem known as the "Insened Record Problem" is described. Next,a related problem with the nom de plume of the "Deleted Record Problem" ispresented. Third, an anomaly associated with the End-Of-File or EOF isdiscussed. Fourth, an overview of the locking modes available in Enscribe ispresented. Finally, all of this is tied together by examining the issues relatingthe Enscribe and the various degrees of consistency.

10.1. Enscribe: The Inserted Record Problem

Section 9.1 described the inconsistent analysis problem and how atransaction with degree three consistency doesn't have the problem. Asdiscussed above, a transaction T can achieve degree three consistency byfollowing these two locking rules:

( a) T sets an exclusive lock on any data that it writes. This lock mustbe held until T commits or abons.

(b) T sets a share lock on any data that it reads. This lock must beheld until T commits or abons.

It turns out that there can be subtle interpretations of how transactionT "sets a share lock on any data that it reads". Enscribe has one of these subtleflaws relating to the insenion of records.


TMF Application Programming InterfaceSection 10:Consistency and Concurrency in Enscribe

Version 1.02/15/89

Please examineFigure 13. This demonstrates the interactionbetween two trans-actions: Tl and T2. Inthis example. Tl isexamining a range ofrecords from "Ann"through "Franco". Itwill process this rangeof records twice.

The first time thatthe range of records isprocessed, there are fiverecords visible in therange: "Ann". "Ben"."Charlie". "Eddie". and"Franco".

After T1 has processed the records. T2comes along and insertsthe record "Don". This isnot prevented inEnscribe because thereare no locks on rangesof records. only onindividual records.

Later. Tl reprocesses the range of records. This time. it seesthe record "Don" whichit did not see before.This could not happengiven degree threeconsistency. It is notpossible in Enscribe toalways lock the dataread by the transaction.

NonStop SQL doesnot have this problem.The details of themechanism used toeliminate the problemare beyond the scope ofthis document.

Page 34

.-.... .... .... .... .... ....~ ~ ... ~ ~ ~

i >. >. >. >. >..0 .0 .0 .0 .0

"t:l "i "i "i "i "i~ ~

~ ~ ~ ~

8 (J g (J (J0 0 0 0

...J ...J ...J ...J ...J ...J

II: II: '" '".~ '" 0 .~ '" 0II: -.::: 0) 0

II: II: -.::: .~ 0II: :c c: c:c: c: as as c: c: as "C asc: 0) oJ:: "C ... c: 0) oJ:: "C ...< CD c.:> UJ LL. < CD c.:> UJ LL.'" '" '" '" '" '" '" '" '" '""E "E "E "E "E "E "E "E "C "E...0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 00) 0) 0) Q) CD Q) Q) CD CD CDa: a: a: a: a: a: a: a: a: a:

A bunch of

+tRead First Read Nexts

(Transaction T1 ) (Transaction T1)

Step 1: Transaction T1 Step 2: Transaction T1 doesstarts reading through the a whole bunch of Read Nextsrecords. up to key -F-.

.... .... .... .... .... .... - - .... ....~ ~ ~ ~ ~ ~ ~ ~ ~ ~

>. i i i i i i i i i.0"t:l "t:l "t:l "t:l "t:l "t:l "t:l "t:l "t:l "t:lG) G) G) G) G) G)

~G)

~G)

~ ~ ~ ~ ~ ~ ~ ~

.9 8 8 8 8 8 8 8 8 8...J ...J ...J ...J ...J ...J ...J ...J ...J

'" '" ~~ =0.~"'0)

0"'Q)

II: II: -.::: II: 0"'c: '" -.:::

'"0

c: c: as c: :c c: c: as c: :c c:c: Q) oJ:: 0 "C as c: 0) oJ:: 0 "C as

CD c.:> ... < CD c.:> ...< Q UJ LL. Q UJ LL.'" II: II: II: '" '" '" '" '" '" '" '""E "E "E '1J "C "C "E "E "E "C "C "C... ... ... ... ... ...0 0 0 0 0 0 0 0 0 0 0 0~

0 0 0 0 0 0 0 0 0 0 0Q) Q) Q) 0) Q) CD CD Q) 0) Q) CDa: a: a: a: a: a: a: a: a: a: a: a:T1 is

+surprisedto see -Don".

Step 3: Transaction T2 Step 4: T1 starts over atinserts the record -Don-. -Ann- and performs ReadTransaction T2 commits. Nexts through the records.

Fig 13: The Insert Problem

Tandem Computers. Incorporated

Version 1.02/15/89


" ">-.~gca ca:::EZ" ""C"C.... ....0·0

~ ~a: a:

Step 1: Transaction T3 Step 2: Transaction T4 readsdeletes record -Paul- from and processes all records inthe file. the range -Mary- to -Robert-

~ ~ ~ ~ ~ ~ ~ ~~ ~ ~

~ ~ ....~

~ ~.ii .:JI:. .ii .ii .ii .ii .:JI:. .:JI:.

8 (J 8 (J (J (J 8 (J (J0 0 0 0 0 0

...J ...J ...J ...J ...J ...J ...J ...J ...J ...J ...J

s s ..">-.

.. ..s >-. >-. 1:: >- t:s (J s .. (J>-. (J

.~!... c: Q) >-. (J

.~!... c: Q).... c: :j .Ll .... c: :j .Llca

~ 0 eu :j 0 eu~ 0 eu :j a:::E a. 0 a: :::E a. 0 a:s s .. s s .. s .. .. .. =

"E "E "E "E "C "E "E 'E "E "E "E "00

.... ....g g 0 0 0 a 0 a 0 0 a(J (J (J (J (J (J (J (J (J (JQ) Q) Q) Q) Q) Q) Q)

~Q) Q) Q) Q)a: a: a: a: a: a: a: a: a: a: a:

Step 3: Transaction T3 aborts Step 4:Transaction T4 rereads

and record -Paul- is the file. It is surprised to see

reinserted into the file. record -Paul-.

Rg 14: The Delete Problem

This is a veryserious problem. T4 hasbeen allowed to see theeffects of an uncommitted transaction (T3).

Later on. T3 may ....----------....-----------..fabon. Then. as T4 rescans the records. it willsee record "Paul". Thiswill give it a different ....----------....-----------...view of the file than itsaw the first time.

This problemonly occurs in Enscribe.NonStop SQL prevents itfrom occurring. SQLalters the example inFigure 14 by blockingtransaction T4 after itscans record "Ollie".Transaction T4 remainsblocked until T3 completes. If T3 commits.SQL returns "Quincy" as 1-----------;1------------1the next record. Iftransaction T3 aborts,then T4 would see thereinserted "Paul" as the I-----------....I-----------~next record.

10.2. Enscribe: The Deleted Record Problem

The deleted record problem is a consequence of not being able to lock allof the effects of an incomplete transaction from being viewed by otherconcurrent transactions. This problem occurs within Enscribe when onetransaction deletes a record and then abons while another transaction isreading through a range of records in a file.

Please examine Figure 14. This example stans out with transaction T3deleting the record "Paul". This removes the record from the file and causes alock to be placed on "Paul" for transaction T3.

Next, along comestransaction T4. It stansreading the file from"Mary" to "Roben". Because "Paul" was deleted.transaction T4 will notsee "Paul" , but will scootpast and ex amine"Quincy" and "Roben".


TMF Application Programming InterfaceSection 10:Consistency and Concurrency in Enscribe

Version 1.02/15/89

EOFLater Insertion

Earlier Insertion

.. .. N ..~ ~ I- ~

o u..OJ w< 0• •

Fig 15. The EOF Anomaly

10.3. The EOF Anomaly

The EOF Anomaly is not really a problem that violates any of the degreesof consistency. It is an unexpected weirdness that results from a performancetrade-off. Given the performance trade-off, it is a wonderful feature.

As described above, a transaction seeing degree one consistency orgreater will place a lock on any object that it writes. This lock will surviveuntil the completion of the transaction. TMF enforces this for all transactionsso that it can avoid the cascading backouts problem (see section 10.3).

Enscribe allows files of type ENTRY-SEQUENCED. NonStop SQL allowstables to be defined as ENTRY-SEQUENCED Tables. For convenience, these willalso be referred to as ENTRY-SEQUENCED files. Whenever a record is written toand ENTRY-SEQUENCED file. it is always appended to the end of the file. Youcannot delete records from an ENTRY-SEQUENCED file (with a special exceptionfor transaction backout). When a record is written, it is placed at the locationin the file known as the E 0 F or End - 0 f -F ite . As the record is written to theEOF. the EOF is advanced so the next record will go to a different location. Latertransactions that read the file will see the records in Entry-Sequence.

So. the act of writing to the end of the file causes the EOF locationpointer to be modified. According to the locking protocols for degree one (andgreater) consistency. the EOF must be locked and not changed until thetransaction has completed. To do this would mean that an ENTRY-SEQUENCED filecould only be written by one transaction at a time. This would impose asevere performance restriction on their usefulness.

To avoid this, TMF ...-------------------....does not cause the EOF to belocked. This lets concurrent transactions interleave their records.

Figure 15 showsthree transactions: T1. T2,and T3 all concurrentlyinserting into an EN TRY SEQUENCED file. Note thatthe records from the threetransactions are allowed tobe interleaved.

This is considered to be an anomaly. rather than a real problem becausea transaction cannot detect this unless it examines the record address valuesassociated with its records. The transaction could deduce that interveningrecords were written. This is considered to be unlikely to cause unexpectedconcurrency problems. It is also possible to detect this behavior when theENTR Y-SEQUENCED file is read later. It is expected that the reading transactionwill be prepared to encounter intermingled records.

Note that while NonStop SQL allows records to intermingle in thisfashion, it is essential to a relational database management system that noinformation is based on the record address. Hence, the records may beintermingled and there can be no meaning associated with the intermingling.


Version 1.02/15/89


10.4. Enscribe: Locking Modes

An Enscribe application has a choice about how it deals with lockconflicts with another transaction. The normal mode is to suspend whenencountering another transaction's handiwork. Options exist that allow theapplication to notice when another transaction holds a lock on the data item.This allows' the second application to do something beside suspend for the lock.

Another possibility must be considered for READ operations. Someapplications wish to REA D- T H R U any locks that may exist and simply returnthe value in the locked record. This is allowed even if the transaction thatchanged the record might later abort. making the value invalid.

When considering the behavior of the second application. it isimportant to differentiate between the various operations that it may beperforming when the locks are encountered. ARE AD operation is differentfrom the more stringent READLOCK. The READLOCK. LOCKRECORD. andREA DU PDATE U N L 0 CK operations have the same locking rules as any of theW RITE operations that will modify the database.

The following options may be selected by the application on a file-byfile basis. They are selected via a SETMODE operation.

• Nor ma I -- Any lock conflict causes the application to suspend.

• Reject -- Any lock conflict causes the request to be rejected with anFELOCKED (73) error.

• ReadThru/Normal -- READs are allowed to READ-THRU and see thecontents of the locked record. READ LOCKs and WRITEs suspend.

• ReadThru/Reject -- READs are allowed to READ-THRU locks.READLOCKs and WRITEs return an FELOCKED (73) error.

• Rea d War n I Nor m a I -- RE ADs return an FE REA D L 0 C KED (9)warning.with the record just read. READLOCKs and WRITEs suspend.

• ReadWarn/Reject -- READs return an FEREADLOCKED (9) warningwith the record. READLOCKs and WRITEs return an FELOCKED (73) error.

In Enscribe. all locks are exclusive locks. There is no ability to set ashare lock on an item read so that the lock may be shared by another reader.This does not affect the consistency of the transactions. It does. however.reduce the possible concurrency by causing one reading transaction tosuspend behind another reading transaction.


TMF Application Programming InterfaceSection lO:Consistency and Concurrency in Enscribe

Version 1.02/15/89

10.5. Enscribe: Degrees of Consistency

In Enscribe. it is possible to get degree one consistency. Using normalrecord locking. you can only get close to seeing either degree two or degreethree consistency. Let's break down the cases by the desired consistency:

Degree Three Application Rules:To approximate degree three consistency. the applicationprogrammer should always avoid the use of the RE ADoperation which allows locks to be released before thetransaction has completed.Issues:In attempting to achieve degree three consistency, both thedeleted record problem and the inserted record problem willprevent the full consistency required.• Whenever two transactions interact as a consequence of

the deleted record problem, the transaction that observesthe inconsistency will be experiencing a form of theuncommitted dependency problem. It will see no betterthan degree one consistency. There is no way to avoid thisin Enscribe short of eliminating READ NEXT operations lwithin the transaction needing higher consistency.

• Whenever two transactions interact as a consequence ofthe inserted record problem. the transaction observing theproblem will see a form of the inconsistent analysisproblem. It will see (at best) degree two consistency.

Degree Two Application Rules:To approximate degree two consistency, the applicationprogrammer may use the READ verb to perform reads of thedatabase that he does not want to remain locked until thetransaction completes. It is important that the file notreceive a SETMODE that allows READ-THRU. To be degree twoconsistent. the READ verb should wait for existing locks.Issues:In attempting to achieve degree two consistency, the insertedrecord problem is not a problem. When this strikes, itreduces the consistency to degree two. The deleted recordproblem is. however. a menace. As described above, it canreduce the consistency to degree one.

Degree One Application Rules:To achieve degree one consistency. the applicationprogrammer may use the RE AD verb to perform reads of thedatabase. Furthermore. it is allowable to use the SETM 0 DEoptions that provide READ-THRU.Issues:None. TMF ensures that a transaction always see at leastde2ree one consistency.

It is worth noting that an application canconsistency in Enscribe by using file locking.effects on concurrency.

obtain full degree threeThis, of course. has drastic


Version 1.02/15/89


11. Locks and Lock Release

The concurrency control mechanism implemented for both SQL andEnscribe is based on locking. Sections 9 and 10 discuss the ways in which thevarious locking techniques can affect the consistency of transactions.

This section describes a couple of esoteric locking issues that, whilepotentially visible to the application. should not affect the consistency of thetransactions executed on the behalf of the application. Please note that thisdiscussion only applies to locks held on audited Enscribe files or audited SQLtables.

In general. TMF maintains LOCKs on the items read or written by atransaction. TMF enforces a two phased locking strategy[Gray7 8]. When atransaction is committed. the locks for the transaction are immediatelyreleased. When a transaction aborts. the locks for the transaction are helduntil BACKOUT completes. BACKOUT, executing independent of the application,may race with the application and occasionally cause the application to wait.

11.1 Waited ABORTTRANSACTION

When the single threaded application calls ENDTRANSACTION for a localtransaction it waits for the transaction to be committed and for the locks to bereleased. The requester is guaranteed that it may begin a new transaction andthe new transaction cannot encounter any of the locks of the just-committedtransaction. This can be a very important issue for applications that do notqueue on locks (Le.• accept the FELOCKED error 73) and perform multipletransactions against the same set of records.

If a transaction aborts. the application does not wait for the effects ofthe transaction to be removed from the system. Instead, the application iscontinued before BA C K 0 UT runs. This allows a window where the nexttransaction of the application will hit the locks from the previous transaction.

To avoid this. some customers have requested a wa i tedABORTTRANSACTION option which would suspend the application until afterB ACK0 UT is complete. At this time. no plans exist to provide this function. If amechanism does get proposed to allow this. it would be nice if it could addressthe network issues discussed above. To do so would require additionalcoordination amongst the nodes of the network transaction to communicatewhen the locks had been released. It is not clear that this is a good idea.



Version 1.02/15/89

11.2. Locks Held for BACKOU T

When a transaction aborts, all of the locks acquired by it are held untilits work is completely undone by the BACKOUT process. This is (almost always)true for both the READ and WRITE locks for the transaction.

It is imperative that the system retain the write locks on recordschanged by the transaction until after BA CK0 UT has completed. This preventsanother transaction from seeing the incorrect values assigned by the failedtransaction l . The READ locks are held until BACKOUT completes because it iseasier for TMF. .

A special case may sometimes cause the READ locks to be released priorto the completion of BACK0 UT. If a disc-process primary CPU dies, the activetransactions that touched the disc-process will be aborted. As the backup discprocess takes over the job previously held by the primary disc-process, it isguaranteed to remember the WRITE locks that may be needed for BACKOUT. TheREAD locks may be released with the failure of the primary disc-process. Thiscan cause a different view of the lock release timings, depending on the causeof the transaction's abort. There is nothing wrong with the early release ofthe READ locks, it's just difficult to accurately explain the rules.

11.3. Asynchronous Network Lock Release

When a network transaction completes, there are no promises madeabout the order of the lock releases. The requester will receive confirmationthat the transaction has committed and then, if it attempts a new transactionwhich accesses the records on the remote node, it mayor may not run into itsold locks. This is especially bad for transactions that abort. The lock release isthen dependant on the BACKOUTs in the different systems. Many differentpossibilities for timing problems exist.

1 This was discussed in greater detail in Section 9.3.


Version 1.02/15/89

TMF Application Programming InterfaceSection 12: Summary

12. Summary

In this document, I have attempted to present the interface to TMF fromthe viewpoint of an application program. To do this, many different topicshave been 'Covered:

• The semantics of a TMF requester were explained. This included adiscussion of BEGINTRANSACTION and ENDTRANSACTION. The concept of acurrent transaction was introduced along with a description of thenotion that the current transaction is propagated to a TMF serverwhenever work for the transaction is subcontracted.

• The issues relating to context-free servers and their use in TMFtransaction was discussed. This included a description of how the serverinherits a transaction as a part of the incoming request. Thistransaction becomes the server's current transaction.

• Next. a discussion was presented of the guarantees of atomicity that TMFmakes to servers while they are processing a request. These issues areall described as the unilateral abort mechanism.

• The techniques by which a single GUARDIAN process may manage manyconcurrent transactions were covered. This included specialconsiderations for both requesters and servers.

• Next, a discussion followed on the reasons why a program would wish tohave a nil current transaction. This included several techniques foraccomplishing this.

• The issues relating to the asynchronous aborting of a transaction werecovered.

• A section was presented on the techniques for writing NonStopapplications that run in conjunction with TMF. This includeddiscussions of why NonStop TMF servers don't exist. NonStop singlethreaded requesters. and NonStop multi-threaded requesters.

• Next, the issues relating to degrees of consistency and NonStop SQL werecovered. This included a presentation of three different concurrencyproblems that may be encountered. The relationship between thesedegrees of consistency and NonStop SQL's access modes was discussed.

• Next. Enscribe and its specific concurrency issues was discussed. Thissection described two concurrency problems with Enscribe and ananomaly in Enscribe relating to its use of Entry-Sequence files. Thevarious locking modes available in Enscribe were discussed. Thissection concluded with a discussion of how to best approximate thevarious degrees of consistency in Enscribe.

• Finally. some esoteric details about lock release were described.

Hopefully. this document has described the TMF ApplicationProgramming Interface adequately to provide a basis for further plannedwork that intends to contrast and compare this interface with others in theindustry. By doing this. it is hoped that the best features of all of theseinterfaces may eventually be incorporated into TMF..


TMF Application Programming InterfaceSections 13 and 14: Acknowledgements and References

13. Acknowledgements

Version 1.02/15/89

I would like to thank Andrea Borr, Jim Carley, Howard Cohen,Phil Garrett, Jim Gray, Dave Hege, Tim Hill, Rodney Limprecht, Jim Lyon,Matt McCline, Mark Moore, Rod Norden, Goran Olsson, Franco Putzolu,Roben Shaw, Don Slutz, and Judy Robbins for their thoughtful (and sometimepainful) comments.

14. References

[DATE84]

[ESWA74]

[LEMB82]

[GRAY76]

[Gray78]

Page 42

Date, C. J., A Guide to DB2, Addison-Wesley. 1984.

Eswaran, K.P., Gray LN., Lorie, R.A., and Traiger LL."On the Notions of Consistency and Predicate Locks", TechnicalReport RJ. 1487, IBM Research Laboratory, San Jose, Ca.,Nov. 1974.

Lemberger, Tony. "Implementing TMF In a Multi-ThreadedNonStop Requester" in Tandem FOCUS. Volume 2, No.3. pp.17 - 22.August 1982.

Gray, J., Lorle, R., Putzolu, F., and Traiger, I.L., "Granularity ofLocks and Degrees of Consistency in a Large Shared Data Base".In Modeling in Data Base Management Systems.Elsevier Nonh-Holland, New York, pp. 365-394. 1976.

Gray, J. "Notes on Data Base Operating Systems".In Lecture Notes on Computer Science, vol 60,R. Bayer, R.N. Graham, and G. Seegmueller, Eds. Springer-Verlag,New York. pp 393-481. 1978.

Tandem Computers, Incorporated

0'

Distributed by."TANDEM

Corporate Information Center19333 Valko Parkway MS3-07Cupertino, CA 95014-2599

the tmf application programming interface · transaction related issues, the interface is presented...

Documents