事务处理:概念与技术(英文影印版)(图灵奖得主不朽经典)

.exercises　44
answers　46
2　basic computer science terminology　47
2.1　introduction　47
2.1.1　units　47
2.2　basic hardware　48
2.2.1　memories　49
2.2.2　processors　57
2.2.3　communications hardware　58
2.2.4　hardware architectures　59
2.3　basic software——address spaces, processes, sessions　62
2.3.1　address spaces　62
2.3.2　processes, protection domains, and threads　63
2.3.3　messages and sessions　66
2.4　generic system issues　67
2.4.1　clients and servers　67
2.4.2　naming　69
2.4.3　authentication　70
2.4.4　authorization　71
2.4.5　scheduling and performance　72
2.4.6　summary　74
2.5　files　74
2.5.1　file operations　74
2.5.2　file organizations　75
2.5.3　distributed files　77
2.5.4　sql　78
2.6　software performance　78
2.7　transaction processing standards　80
2.7.1　portability versus interoperability standards　80
2.7.2　apis and faps　80
2.7.3　lu6.2, a de facto standard　82
2.7.4　osi-tp with x/open dtp, a de jure standard　83
2.8　summary　85
exercises　86
answers　88
part two——the basics of fault tolerance
3　fault tolerance　93
3.1　introduction　93
3.1.1　a crash course in simple probability　93
3.1.2　an external view of fault tolerance　95
3.2　definitions　98
3.2.1　fault, failure, availability, reliability　98
3.2.2　taxonomy of fault avoidance and fault tolerance　99
3.2.3　repair, failfast, modularity, recursive design　100
3.3　empirical studies　100
3.3.1　outages are rare events　100
3.3.2　studies of conventional systems　101
3.3.3　a study of a fault-tolerant system　103
3.4　typical module failure rates　105
3.5　hardware approaches to fault tolerance　109
3.5.1　the basic n-plex idea: how to build failfast modules　109
3.5.2　failfast versus failvote voters in an n-plex　109
3.5.3　n-plex plus repair results in high availability　112
3.5.4　the voter's problem　113
3.5.5　summary　115
3.6　software is the problem　115
3.6.1　n-version programming and software fault tolerance　116
3.6.2　transactions and software fault tolerance　117
3.6.3　summary　119
3.7　fault model and software fault masking　119
3.7.1　an overview of the model　120
3.7.2　building highly available storage　122
3.7.3　highly available processes　128
3.7.4　reliable messages via sessions and process pairs　138
3.7.5　summary of the process-message-storage model　147
3.8　general principles　148
3.9　a cautionary tale——system delusion　149
3.10　summary　150
3.11　historical notes　151
exercises　152
answers　155
part three——transaction-oriented computing
4　transaction models　159
4.1　introduction　159
4.1.1　about this chapter　160
4.2　atomic actions and flat transactions　160
4.2.1　disk writes as atomic actions　161
4.2.2　a classification of action types　163
4.2.3　flat transactions　165
4.2.4　limitations of flat transactions　171
4.3　spheres of control　174
4.3.1　definition of spheres of control　174
4.3.2　dynamic behavior of spheres of control　176
4.3.3　summary　180
4.4　a notation for explaining transaction models　180
4.4.1　what is required to describe transaction models?　181
4.4.2　elements of the notation　183
4.4.3　defining transaction models by a set of simple rules　184
4.5　flat transactions with savepoints　187
4.5.1　about savepoints　187
4.5.2　developing the rules for the savepoint model　189
4.5.3　persistent savepoints　190
4.6　chained transactions　192
4.7　nested transactions　195
4.7.1　definition of the nesting structure　195
4.7.2　using nested transactions　198
4.7.3　emulating nested transactions by savepoints　200
4.8　distributed transactions　202
4.9　multi-level transactions　203
4.9.1　the role of a compensating transaction　204
4.9.2　the use of multi-level transactions　206
4.10　open nested transactions　210
4.11　long-lived transactions　210
4.11.1　transaction processing context　212
4.11.2　the mini-batch　215
4.11.3　sagas　217
4.12　exotics　219
4.13　summary　221
4.14　historical notes　222
exercises　225
5　transaction processing monitors——an overview　239
5.1　introduction　239
5.2　the role of tp monitors in transaction systems　239
5.2.1　the transaction-oriented computing style　241
5.2.2　the transaction processing services　249
5.2.3　tp system process structure　252
5.2.4　summary　258
5.3　the structure of a tp monitor　259
5.3.1　the tp monitor components　260
5.3.2　components of the transaction services　263
5.3.3　tp monitor support for the resource manager interfaces　266
5.4　transactional remote procedure calls: the basic idea　267
5.4.1　who participates in remote procedure calls?　267
5.4.2　address space structure required for rpc handling　268
5.4 3　the dynamics of remote procedure calls　270
5.4.4　summary　273
5.5　examples of the transaction-oriented programming style　274
5.5.1　the basic processing loop　275
5.5.2　attaching resource managers to transactions: the simple cases　276
5.5.3　attaching resource managers to transactions: the sophisticated case　282
5.5.4　using persistent savepoints　284
5.6　terminological wrap-up　285
5.7　historical notes　286
exercises　288
answers　289
6　transaction processing monitors　293
6.1　introduction　293
6.2　transactional remote procedure calls　295
6.2.1　the resource manager interface　297
6.2.2　what the resource manager has to do in support of transactions　299
6.2.3　interfaces between resource managers and the tp monitor　301
6.2.4　resource manager calls versus resource manager sessions　304
6.2.5　summary　312
6.3　functional principles of the tp monitor　312
6.3.1　the central data structures of the tpos　313
6.3.2　data structures owned by the tp monitor　318
6.3.3　a guided tour along the trpc path　324
6.3.4　aborts racing trpcs　331
6.3.5　summary　332
6.4　managing request and response queues　333
6.4.1　short-term queues for mapping resource manager invocations　335
6.4.2　durable request queues for asynchronous transaction processing　336
6.4.3　summary　347
6.5　other tasks of the tp monitor　347
6.5.1　load balancing　347
6.5.2　authentication and authorization　354
6.5.3　restart processing　360
6.6　summary　362
6.7　historical notes　364
exercises　366
answers　368
part four——concurrency control
7　isolation concepts　375
7.1　overview　375
7.2　introduction to isolation　375
7.3　the dependency model of isolation　378
7.3.1　static versus dynamic allocation　378
7.3.2　transaction dependencies　379
7.3.3　the three bad dependencies　380
7.3.4　the case for a formal model of isolation　381
7.4　isolation: the application programmer's view　382
7.5　isolation theorems　383
7.5.1　actions and transactions　383
7.5.2　well-formed and two-phased transactions　385
7.5.3　transaction histories　385
7.5.4　legal histories and lock compatibility　386
7.5.5　versions, dependencies, and the dependency graph　387
7.5.6　equivalent and isolated histories: before, after, and wormholes　388
7.5.7　wormholes are not isolated　389
7.5.8　summary of definitions　390
7.5.9　summary of the isolation theorems　396
7.6　degrees of isolation　397
7.6.1　degrees of isolation theorem　398
7.6.2　sql and degrees of isolation　398
7.6.3　pros and cons of low degrees of isolation　400
7.6.4　exotic sql isolation——read-past and notify locks　402
7.7　phantoms and predicate locks　403
7.7.1　the problem with predicate locks　405
7.8　granular locks　406
7.8.1　tree locking and intent lock modes　406
7.8.2　update mode locks　409
7.8.3　granular locking summary　410
7.8.4　key-range locking　411
7.8.5　dynamic key-range locks: previous-key and next-key locking　412
7.8.6　key-range locks need dag locking　414
7.8.7　the dag locking protocol　415
7.8.8　formal definition of granular locks on a dag　417
7.9　locking heuristics　419
7.10　nested transaction locking　421
7.11　scheduling and deadlock　422
7.11.1　the convoy phenomenon　423
7.11.2　deadlock avoidance versus toleration　424
7.11.3　the wait-for graph and a deadlock detector　425
7.11.4　distributed deadlock　426
7.11.5　probability of deadlock ..　428
7.12　exotics　429
7.12.1　field calls　430
7.12.2　escrow locking and other field call refinements　432
7.12.3　optimistic and timestamp locking　434
7.12.4　time domain addressing　435
7.13　summary　437
7.14　historical notes　438
exercises　440
answers　442
8　lock implementation　449
8.1　introduction　449
8.1.1　about this chapter　449
8.1.2　the need for parallelism within the lock manager　449
8.1.3　the resource manager and lock manager address space　450
8.2　atomic machine instructions　452
8.3　semaphores　454
8.3.1　exclusive semaphores　454
8.3.2　crabbing: traversing shared data structures　456
8.3.3　shared semaphores　458
8.3.4　allocating shared storage　461
8.3.5　semaphores and exceptions　462
8.4　lock manager　464
8.4.1　lock names　464
8.4.2　lock queues and scheduling　465
8.4.3　lock duration and lock counts　467
8.4.4　lock manager interface and data structures　469
8.4.5　lock manager internal logic　471
8.4.6　lock escalation and generic unlock, notify locks　477
8.4.7　transaction savepoints, commit, and rollback　478
8.4.8　locking at system restart　479
8.4.9　phoenix transactions　480
8.4.10　lock manager configuration and complexity　481
8.4.11　lock manager summary　481
8.5　deadlock detection　481
8.6　locking for parallel and parallel nested transactions　483
8.7　summary　484
8.8　historical notes　485
exercises　485
answers　488
part five——recovery
9　log manager　493
9.1　introduction　493
9.1.1　uses of the log　493
9.1.2　log manager overview　494
9.1.3　the log manager's relationship to other services　495
9.1.4　why have a log manager?　496
9.2　log tables　496
9.2.1　mapping the log table onto files　497
9.2.2　log sequence numbers　499
9.3　public interface to the log　500
9.3.1　authorization to access the log table　500
9.3.2　reading the log table　500
9.3.3　writing the log table　502
9.3.4　summary　503
9.4　implementation details of log reads and writes　504
9.4.1　reading the log　504
9.4.2　log anchor　505
9.4.3　transaction related anchors　505
9.4.4　log insert　506
9.4.5　allocate and flush log daemons　507
9.4.6　careful writes: serial or ping-pong　508
9.4.7　group commit, batching, boxcarring　509
9.4.8　wads writes　510
9.4.9　multiple logs per transaction manager　511
9.4.10　summary　511
9.5　log restart logic　511
9.5.1　saving the transaction manager anchor　512
9.5.2　preparing for restart: careful writes of the log anchor　512
9.5.3　finding the anchor and log end at restart　513
9.6　archiving the log　514
9.6.1　how much of the log table should be online?　514
9.6.2　low-water marks for rollback, restart, archive　515
9.6.3　dynamic logs: copy aside versus copy forward　516
9.6.4　archiving the log without impacting concurrent transactions　517
9.6.5　electronic vaulting and change accumulation　518
9.6.6　dealing with log manager-archive circularity　519
9.7　logging in a client-server architecture　519
9.8　summary　520
9.9　historical notes　521
exercises　521
answers　523
10　transaction manager concepts　529
10.1　introduction　529
10.2　transaction manager interfaces　529
10.2.1　the application interface to transactions　531
10.2.2　the resource manager interface to transactions　534
10.2.3　transaction manager functions　536
10.3　transactional resource manager concepts　538
10.3.1　the do-undo-redo protocol　538
10.3.2　the log table and log records　540
10.3.3　communication session recovery　541
10.3.4　value logging　545
10.3.5　logical logging　546
10.3.6　physiological logging　548
10.3.7　physiological logging rules: fix, wal, and force-log-at-commit　550
10.3.8　compensation log records　558
10.3.9　idempotence of physiological redo　560
10.3.10　summary　561
10.4　two-phase commit: making computations atomic　562
10.4.1　two-phase commit in a centralized system　563
10.4.2　distributed transactions and two-phase commit　567
10.5　summary　573
10.6　historical notes　574
exercises　576
answers　578
11　transaction manager structure　585
11.1　introduction　585
11.2　normal processing　585
11.2.1　transaction identifiers　586
11.2.2　transaction manager data structures　586
11.2.3　mytrid(), status_transaction(), leave_transaction(), resume_transaction()　590
11.2.4　savepoint log records　591
11.2.5　begin work()592
11.2.6　local commilwork().　593
11.2.7　remote commit_work(): prepare() and commit()　596
11.2.8　save_work() and read_context()　599
11.2.9　rollback_work()　601
11.3　checkpoint　604
11.3.1　sharp checkpoints　605
11.3.2　fuzzy checkpoints　606
11.3.3　transaction manager checkpoint　607
11.4　system restart　609
11.4.1　transaction states at restart　610
11.4.2　transaction manager restart logic　610
11.4.3　resource manager restart logic, identify()　613
11.4.4　summary of the restart design　616
11.4.5　independent resource managers　616
11.4.6　the two-checkpoint approach: a different strategy　616
11.4.7　why restart works　618
11.4.8　distributed transaction resolution: two-phase commit at restart　620
11.4.9　accelerating restart　620
11.4.10　other restart issues　621
11.5　resource manager failure and restart　622
11.6　archive recovery　622
11.7　configuring the transaction manager　624
11.7.1　transaction manager size and complexity　624
11.8　summary　624
exercises　625
answers　626
12　advanced transaction manager topics　631
12.1　introduction　631
12.2　heterogeneous commit coordinators　631
12.2.1　closed versus open transaction managers　632
12.2.2　interoperating with a closed transaction manager　632
12.2.3　writing a gateway to an open transaction manager　635
12.2.4　summary of transaction gateways　638
12.3　highly available (non-blocking) commit coordinators　638
12.3.1　heuristic decisions resolve blocked transaction commit　640
12.4　transfer-of-commit　641
12.5　0ptimizations of two-phase commit　643
12.5.1　read-only commit optimization　644
12.5.2　lazy commit optimization　645
12.5.3　linear commit optimization　645
12.6　disaster recovery at a remote site　646
12.6.1　system pair takeover　648
12.6.2　session switching at takeover　649
12.6.3　configuration options: 1-safe, 2-safe, and very safe　651
12.6.4　catch-up after failure　652
12.6.5　summary of system pair designs　653
12.7　summary　654
12.8　historical notes　654
exercises　655
answers　656
part six——transactional file system:a sample resource manager
13　file and buffer management　661
13.1　introduction　661
13.2　the file system as a basis for transactional durable storage　662
13.2.1　external storage versus main memory　662
13.2.2　the external storage model used in this book　668
13.2.3　levels of abstraction in a transactional file and database manager　671
13.3　media and file management　673
13.3.1　objects and operations of the basic file system　673
13.3.2　managing disk space　677
13.3.3　catalog management for low-level file systems　686
13.4　buffer management　688
13.4.1　functional principles of the database buffer　689
13.4.2　implementation issues of a buffer manager　697
13.4.3　logging and recovery from the buffer's perspective　708
13.4.4　optimizing buffer manager performance　714
13.5　exotics　723
13.5.1　side files　724
13.5.2　single-level storage　732
13.6　summary　738
13.7　historical notes　739
exercises　741
answers　744
14　the tuple-oriented file system　751
14.1　introduction　751
14.2　mapping tuples into pages　752
14.2.1　internal organization of pages　752
14.2.2　free space administration in a file　757
14.2.3　tuple identification　760
14.3　physical tuple management　768
14.3.1　physical representation of attribute values　769
14.3.2　physical representation of short tuples　772
14.3.3　special aspects of representing attribute values in tuples　784
14.3.4　physical representation of long tuples　786
14.3.5　physical representation of complex tuples and very long attributes　791
14.4　file organization　794
14.4.1　administrative operations　795
14.4.2　an abstract view on different file organizations via scans　799
14.4.3　entry-sequenced files　806
14.4.4 system-sequenced files　811
14.4.5　relative files　814
14.4.6 key-sequenced files and hash files　817
14.4.7　summary　818
14.5　exotics　819
14.5.1 cluster files　819
14.5.2 partitioned files　820
14.5.3　using transactions to maintain the file system　821
14.5.4　the tuple-oriented file system in current database systems　822
14.6　summary　823
exercises　824
answers　825
15　access paths　　831
15.1　introduction　831
15.2　overview of techniques to implement associative access paths　833
15.2.1　summary　835
15.3　associative access by hashing　835
15.3.1　folding the key value into a numerical data type　836
15.3.2　criteria for a good hash function　838
15.3.3　overflow handling in hash files　845
15.3.4　local administration of pages in a hash file　848
15.3.5　summary of associative access based on hashing　848
15.4　b-trees　851
15.4.1　b-trees: the basic idea　851
15.4.2　performance aspects of b-trees　861
15.4.3　synchronization on b-trees: the page-oriented view　867
15.4.4　synchronization on b-trees: the tuple-oriented view　868
15.4.5　recovering operations on b-trees　872
15.5　sample implementation of some operations on b-trees　876
15.5.1　declarations of data structures assumed in all programs　876
15.5 2　implementation of the roadkoy operation on a b-tree　878
15.5.3　key-range locking in a b-tree　880
15.5.4　implementation of the insert operation for a b-tree:the simple case　882
15.5.5　implementing b-tree insert: the split case　884
15.5.6　summary　886
15.6　exotics　886
15.6.1　extendible hashing　887
15.6.2　the grid file　892
15.6.3　holey brick b-trees　897
15.7　summary　904
15.8　historical notes　905
exercises　909
answers　911
part seven——system surveys
16　survey of tp systems　917
16.1　introduction　917
16.2　ims　917
16.2.1　hardware and operating system environment　918
16.2.2　workflow model　920
16.2.3　program isolation　923
16.2.4　main storage databases and field calls　923
16.2.5　data sharing　924
16.2.6　improved availability and duplexed systems　925
16.2.7　db2　927
16.2.8　recent evolution of ims　928
16.3　cics and lu6.2　928
16.3.1　cics overview　928
16.3.2　cics services　930
16.3.3　cics workflow　931
16.3.4　cics distributed transaction processing　932
16.3.5　lu6.2　934
16.4　guardian 90　937
16.4.1　guardian: the operating system and hardware　938
16.4.2　pathway, terminal context, and server class management　939
16.4.3　transaction management　941
16.4.4　other interesting features　947
16.5　decdta　947
16.5.1　acms's three-ball workflow model of transaction processing　948
16.5.2　acms services　951
16.5.3　acms summary　952
16.5.4　vms transaction management support　954
16.5.5　summary of decdta　958
16.5.6　reliable transaction router (rtr)　959
16.6　x/open dtp, osi-tp, ccr　960
16.6.1　the local case　962
16.6.2　the distributed case: services and servers　964
16.6.3　summary　964
16.7　other systems　965
16.7.1　universal transaction manager (utm)　965
16.7.2　adabas tpf966
16.7.3　encina　968
16.7.4　tuxedo　970
16.8　summary　972
part eight——addenda
17　references　975
18　data structures and interfaces　993
19　glossary　1003
index ...　1047

.　　Most chapters also have exercises ranging from short refreshers to term projects. The answers to most of them are provided at the end of each chapter. Following Donald Knuth, each exercise has a qualifier of the form [section, level]. The exercise applies to the material in the section indicated. The level is an indicator of how difficult the exercise is:
　　[10] One minute (just to check whether you have followed the text)
　　[20] 15-20 minutes for full answer
　　[25] One hour for full written answer
　　[30] Short (programming) project: less than one full day of work
　　[40] Significant (programming) project: two weeks of elapsed time ..
　　In addition, we have used the ratings [project] for anything that is likely to be higher than [40], and [discussion] for exercises that ask readers to go out and explore a certain subject on their own.
　　The original plan for the book was to include SQL implementation and application de- sign along with transactions. As the work progressed, we realized that there was not space or time for these topics. So, as it stands, this book is about how to implement transactions. Ceri and Pelagatti's excellent book [1984] covers the high-level database issues (SQL, normaliza- tion, optimization, and also some transaction management issues).
　　Learning with this Book
　　The book is intended for advanced undergraduates, graduate students, and for professional programmers who either want to understand what their transaction processing system is do- ing to them (e.g., a CICS/DB2 user) or who need a basic reference text. It assumes that you have a reading knowledge of SQL and C.
　　The content of this book has no exact counterpart among computer science classes at a university. The compartmentalization of subjects is inherent in the structure of the curricu- lum, and as yet there is no standard class on transaction processing. However, the book.has already been used in a variety of undergraduate and graduate courses during our various stages of draft manuscript. We feel the approach we have taken is appropriate within the ex- isting structure of computer science, but we hope that exposure to our approach. will help to eliminate compartmentalized thinking. Here are some suggestions for emphasizing different aspects of the coverage:
　　Just getting the idea: Chapter 1, Sections 2.7, 4.1-4.2, 5.1-5.3, 5.5-5.7, and Chapter 16.
　　An introduction to transaction processing: Chapters 1 and 2, Sections 3.1-3.6, Chapters 4 and 5, Sections 6.4-6.5, 7.1-7.6, Chapters 9, 10, 16.
　　Database systems: Chapters 1, 4, 7, 10, 13, 14, 15.
　　Distributed systems: Chapters 1, 2, 3, 4, 7, 8, 10, 11, 12, 16.
　　Operating systems: Chapters 1, 2, 3, 5, 6, 7, 8, 10, 11, 13, 16.
　　Advanced coverage: Read everything. In advanced courses, Chapters 1 and 3 can be skipped or done away with quickly. In addition, one could use the books by Tanenbaum on operating systems and computer networks, by Ceri and Pelagatti on distributed databases, by Oszu and Valdunez on pnnciples of distributed databases, and one of Date's books on databases in general.
　　Many other combinations are conceivable. Those who are already familiar with the subject can skip Chapters 1 and 2; we recommend browsing them, just to grasp the terminology used throughout the book.
　　Chapter 3 can be skipped, but we recommend you read it. Transactions may seem all too obvious at the first glance. However, Chapter 3 carefully explains why transactions are the fight exception-handling model and are a key to building highly available systems. The techniques described therein help provide a better understanding of what fault tolerance at the system level means, and they can be put to use almost immediately for anyone building applications.
　　We sketched the few dependencies that exist among the chapters while introducing the subject areas. If you read the entire book, you will notice some redundancy among the chapters. This feature allows chapters to be used independently.
　　To enhance course use of this book, instructors might consider using software available from Transarc Corporation through the Encina University Program. The Encina products are designed to enable distributed, standards-based online transaction processing in open com- puting environments. Many of the topics in this book could be explored through course pro- jects using the Encina family of modular products: for example, distributed transaction man- agement, transactional remote procedure calls, advanced lock and recovery models, shared logging systems, a record-oriented resource manager, and a transaction monitor. Contact information about the Encina family of products and academic site licences can be found on the copyright page of this book.
　　If you have time enough, and if you are thoroughly interested in transaction processing, get copies of papers by Bjork and Davies [1972; 1973; 1978]. These early articles started the whole field, and it is instructive to read them from our current perspective. One appreciates that transactions evolved not so much as a natural abstraction, but as a radical attempt to cut out complexity that otherwise proved to be unmanageable. When reading these seminal papers, you will also find that the wsion outlined there has not yet become reahty not by a wide margin.
　　Concluding Remarks
　　As the acknowledgments indicate, drafts of this book were reviewed and class-tested for two years (1990-1991). Not only has this improved the presentation and accuracy of the text, it also changed the overall design of the book. New chapters were added, others were dropped, and the book doubled in size. The review process and heated debates also changed the way the material is organized. One of us started top-down, whereas the other one wrote bottom- up. In the end, we both reversed our approaches.
　　Apart from that, errors remain errors, and they must be blamed on us witn no excuse. We will be very grateful, though, if you let us know the ones you find. Please send such comments to the authors in care of the publisher, or to the electronic mailbox Gray @ microsoft.com.
　　Acknowledgments
　　This book benefited from the detailed criticism and advice of many people. We gratefutly acknowledge their guidance. We are especially grateful to Frank Bamberger, Phil Bernstein, Noel Herbst, Bruce Lindsay, Dave Lomet, Dan Siewxorek, Nand,t Soparkar, Kent Tre,be, and Laurel Wentworth for detailed advice on xmprovmg the emphasis or focus of the book. More than anything else, the criticism of Betty Salzberg and her classes shaped the presentation of this book. Thank you all.
　　Phil Bernstein at Digital Johannes Klein at Digital
　　Frank Bamberger at Citibank Angelica Kokkinaki at Northeastern
　　Edward Brajinski at Digital Jacek Kruszelnicki at Northeastern
　　Mike Carey at Wisconsin Olaf Kruger at Northeastern
　　Stefano Ceri at Milano Lori Ann Lashway at Polaroid
　　Edward Cheng at Digital Don Langenhorst at Northeastern
　　Joe Coffee at Northeastern Bruce Lindsay at IBM
　　Mike Cox at Princeton Dave Lomet at Digital
　　Flaviu Cristian at IBM Randell MacBlane at USL
　　Gary Cuhna at Northeastern Dorthy Minior at GSSI
　　Walker Cunningham at Morgan Kaufmann Elliot Moss at U. Massachusetts
　　Allyn Dimock at Northeastern Ron Obermarck at Digital
　　Robert Drum at Northeastern Jeffry Picciotto at Mitre
　　Dan Duchamp at Columbia Franco Putzolu at Tandem
　　Amanda Carlson at HP Xinyang Qian at Northeastern
　　Jeff Eppinger at Transarc Ron Regan at Northeastern
　　Georgios Evangelidis at Northeastern Dennis Roberson at Digital
　　Scott Fitzgerald at Northeastern Eleana Rosenzweig at Northeastern
　　Hector Garcia-Molina at Princeton Daphne Ryan at Northeastern
　　Amal Gebrael at Northeastern Betty Salzberg at Northeastern
　　Yujia Haung at Northeastern Tom Sawyer at Tom Sawyer
　　Ricky Ho at G.O. Graphics Fabio Schreiber at Milan
　　Walter Hursch at Northeastern Linda Seiter at Northeastern
　　Meichun Hsu at Digital Mark Sherman at Transarc
　　Pat Helland at HAL Dan S iewiorek at CMU
　　Noel Herbst at Tandem Eric Skov at Northeastern
　　Pete Homan at Tandem Donald Slutz at Tandem
　　Olaf Kruger at Northeastern Mark Smith at U. Massachusetts
　　T.J. Jafar at Northeastern Narjit Sindupal at ATT
　　Jim Johnson at Digital Nandit Soparkar at U. Texas
　　Christos Stamelos at Northeastern
　　Kent Treiber at IBM Bill Wisnaskas at Northeastern
　　Mike Ubell at Digital David Wong at Northeastern
　　Tom Vancor at BGS Robert Wu at Digital
　　Vic Vyssotsky at Digital Hans-Jtirg Zeller at Tandem
　　Laurel Wentworth at Digital Ying Zhou at Northeastern
　　Gary Warner at Northeastern
　　Walker Cunningham, our developmental writer, carefully criticized all the chapters. His efforts made an enormous difference in the clarity of the book.
　　Our colleagues heavily influenced certain chapters. Betty Salzberg suggested the need for Chapter 2 (terminology). Dan Siewiorek and Vic Vyssotsky contributed heavily to the chapter on fault tolerance. Bruce Lindsay and Harald Sammer influenced our presentation of transaction concepts. Phil Bernstein, Noel Herbst, Bruce Lindsay, and Ron Obermarck caused us to rethink our presentation of transaction management. Dave Lomet and Franco Putzolu contributed heavily to the chapters on record and file management. Frank Bamberger, Elliot Moss, Don Slutz, and Nandit Sopakar gave us valuable overall criticism of the book.
　　Charlie Davies, the visionary who launched our field 20 years ago, deserves mention here. Charlie's work on spheres of control is little known. His papers are obscure, but all who came in contact with him were inspired by his vision. Workers in the field are still try- ing to work out the details of that vision. Chapter 4 presents his ideas in more modem terms.
　　Transaction processing is a field in which practice has led theory. Commercial systems often implement ideas long before the ideas appear in an academic setting. One is reminded of Galileo claiming the invention of the telescope to the doges of Venice while merchants were selling mass-produced Dutch telescopes in the streets below.
　　Throughout the book, we are faced with a dilemma. Does one give credit to the first to publish an idea? Or, does one give priority to the earlier development and implementation of the idea in a product? Academic tradition and U.S. patent law give priority to the first to publish. We have tried to credit both. The historical notes in each chapter recount, as best we can, the parallel commercial and academic development of the ideas. Perhaps the point is moot; implementors don't want credit for ideas, they want the cash.
　　One implementor, Franco Putzolu, has deeply influenced our field in general, and the authors in particular. Franco has never written a paper or a patent, but his ideas and code are at the core of System R, SQL/DS, DB2, Allbase, and NonStop SQL. These designs have been widely copied by others and are repeated here. Franco Putzolu deserves much of the credit for this book.
　　Bruce Spatz, our publisher, gave us excellent guidance on the focus of the book. He ar- ranged for many reviews, arranged the classroom tests, and encouraged us when we needed it most. We also are very grateful to our project manager, Jennifer Ballentine of Professional Book Center, and Jeanne Thieme, our copyeditor, for their contributions to this book.
　　Andreas's students contributed to the book in many ways: They read draft versions, used it for teaching, tried the exercises, worked on the references, and so on--typical student slave labor. Moreover, the absence of their supervisor when he periodically got serious about "finishing that book now" meant they had to work on their own much more than one would wish.
　　Gabriele Ziegler, Andreas's secretary, deserves special thanks for keeping him orga- nized during the whole endeavor--not an easy assignment. She had to pacify many people who had good reason to be angry for his not responding for days or weeks when he was again "finishing that book now.
　　Christiane Reuter almost wrote a chapter on application design, but decided against it. However, she took care of the authors during the first long writing assignment in Rlpa--not a simpletask given the qualit of the local power and the dreadful weather. She also accepted the multiyera ordeal of late nights and lost weekends.
　　Tandem Computers and Digital Equipment Corporation were very generous In theirsupport of Jim Gray's efforts on this book.
　　Thanks to all of you who kept us going, even kept us amused, and tolerated our obsessions and varying tempers. ...
　　Jim Gray
　　Andreas Reuter
　　University of Stuttgart