Download Operating System Support for Transactions and more Lecture notes Operating Systems in PDF only on Docsity!
Operating System Support for Transactions
Session summary
T r a n s a c t i o n m e c h a n i s m s simplify the construction of reliable systems. T h e y provide u n i f o r m support for invoking and synchronizing operations on shared data objects and for recovering after s y s t e m
failures. Typically. t r a n s a c u o n s have the properties of fadure cuo,mciry, permanence and senaiw_abdlt_v.
Failure a t o m i c i t y ensures that either all or none of a t r a n s a c t l o n s operations are p e r f o r m e d , and p e r m a n e n c e ensures that if a t r a n s a c t i o n completes successfully, the results of its Ol:,erations wdl never be lost. Serializabihty ensures that ,f several transactions e x e c u t e concurrently, they run as if they w e r e e x e c u t e d serially in some order.
This session focused on providing u n i f o r m operating s y s t e m support for transactions that can be used b o t h b y applications and b y servers that i m p l e m e n t special-purpose data abstractions One goal of providing such support in the operating s y s t e m is increased p e r f o r m a n c e. The other goal arises f r o m the o b s e r v a t i o n t h a t a transaction facdity has increased utility if it is uniformly available to a wide collection of subsystems such as databases, fde systems, c o m m u n i c a t i o n packages, etc
T o set a f r a m e w o r k for the session. Alfred Spector (Carnegie-_Mellon University. USA) presented a list of issues in operating s y s t e m support for t r a n s a c t i o n m a n a g e m e n t :
W h a t primitives should be e x p o r t e d by the centralized transaction facihty? Though some are obvious, there are m a n y questions; e. g. relating to the level of the primitives that should be e x p o r t e d , the support for nesting and save-points, etc.
H o w should transaction synchronization, recovery, and c o m m i t m e n t be supported? T h e r e are m a n y k n o w n algorithms, b u t the trade-offs are obscure, particularly as transactions are applied to non-traditional d o m a i n s a n d need higher p e r f o r m a n c e.
H o w should transaction support be divided b e t w e e n s y s t e m components7 For example, should each d a t a abstraction p e r I o r m its o w n r e c o v e r y , or should a single s y s t e m - w i d e r e c o v e r y m e c h a n i s m (e.g., a c o m m o n log) be used?
- What, if any. specialized h a r d w a r e support for r e c o v e r y , c o m m u n i c a t i o n , or possibly s y n c h r o n i z a t i o n should be provided
Spector also raised a few other questions that relate not only to transaction systems, but to other types of s y s t e m s as well:
- H o w should inter-node c o m m u m c a t m n be done. particularly if It m u s t be very h~ghly efficient; e.g.. for supporting object replication
W h a t is the p r o p e r organization for servers7 For example, should they be m u l t i - t h r e a d e d with an internal scheduler or should they use multiple operating s y s t e m prc~:esses that share m e m o r y w h e r e necessary?
- H o w should objects be n a m e d and protected'/
E N C H E R E
In the first project presentation. J -P. Banatre (IRISA. France) described the E N C H E R E distributed auction bidding system. In this system, sellers and buyers use a d~stributed system m order to auction the sellers' wares. The system must provide fairness, a u t o n o m y , high availabdity, and efficzency A collection of application processors accessed from personal workstations is in charge of processing the auction-bidding transactions. Banatre noted that this application benefits greatly from the reeo,,ery and synchronization properties of the general t r a n s a c u o n mechanism.
To support failure atomicity and p e r m a n e n c e for small objects the E N C H E R E project has developed a stable storage device in R A M The stable R A M has 8, non-volatile m e m o r y banks mapped into the address space of the application processor H a r d w a r e faults in these banks are masked by sequentially writing stable objects into two banks. Because the non-volatile R A M is intended to be used by multiple processes, there are m e c h a m s m s that protect against software faults, such as uncontrolled m e m o r y accesses First. there is a register assc~:iated with each bank that governs whether the bank m a y be read and or written. In add~tnon, there is a table, called the Access Table, of length P and width 8. An e n t r y of 1 in the p-i~, row and the c.th column permnts process p to access bank c.
Banatre reported that the E N C H E R E system is currently being transferred to industry and that a follow-on system is under design.
S y s t e m R =
In the following presentation, Bruce Lindsay (IBM San Jose Research L a b o r a t o r y. USA) discussed operating system support for transact,on m a n a g e m e n t in the c o n t e x t of System R*. a distributed database m a n a g e m e n t system developed at IBM San Jose Research. In particular. Llndsay discussed the operating-system facdlUes needed to support transactions and the structure of servers called from within transactions fServers are called services in R= terminology )
Lindsay identified the following operating-system faeihties:
Server registration. With this faedlty, servers can register themselves and the operations provided w h e n they are r e a d y to receive requests This reformation is used by the system to enable clients to access the servers and to give ser,,ers access to their client local, and global contexts when they are called.
Server routing. The operating system performs routing of operation requests to local servers. If a server creates a local c o n t e x t for each client, the operating system must be able to route additional requests within a transaction to the appropriate context. In the R* model, requests are ne~er directly issued to remotely located servers. Instead. they are passed to local servers, whnch then use d a t a - c o m m u m c a t l o n faciht~es to interact with remote ones.
Transaction identifier generation and management. The operating system generates a globally u m q u e transaction zdentiher for each transaction and ensures that it is k n o w n in all the participating execution nodes.
Transaction commitment and aborting. The operatm 8 system coordinates c o m m , t and abort processing. It c o m m u n i c a t e s ~-ith local servers and remote operating systems. ,a,-hich in torn c o m m u n i c a t e wsth their local servers, etc.
P e r s i s t e n t objects
Hans Diel (IBM BObilngen L a b o r a t o r y , W G e r m a n y ) used the limited time available to briefly d,scuss s o m e of his project's w o r k on o p e r a t i n g - s y s t e m support for transactions The facilities being built in this project are intended to support various types_ of fde systems and access methc.ds as well as replicated objects, which he t e r m e d n e t w o r k - g l o b a l objects.
Diel focused on the support for persistent objects Persistent objects are m a p p e d into main m e m o r y
prior to use. To support x ery large objects. Diel discussed the use of ~ir~io~,ing. Windowing permits
an object to be accessed when only part of it is m a p p e d into m e m o r y.
R e c o v e r y of persistent objects is done using s h a d o w paging, only the copy of an object that is m a p p e d into m e m o r y is modified until transaction c o m m , t m e n t. The operating system provides tlae necessary instructions on m a p p e d objects to permit c o m m i t and a b o r t processing. C o n c u r r e n c y control is achieved via locking in five lock mcxdes, including deadlock detection.
G e n e r a l d i s c u s s i o n
Following the presentations, a rather heated interchange occurred on the subject of the efficiency of message passing b e t w e e n protected processes vs. p r o t e c t e d p r o c e d u r e calls. R ° uses the latter and L i n d s a y argued p r o t e c t e d p r o c e d u r e calls were m u c h m o r e efheient. The session was running late. but the discussion wdl p r o b a b l y be continued at SOSP-10.
To conclude this brief s u m m a r y , a reference ,s provided for each of the four projects.
E N C I t E R E : (^) J - P. Banatre. M Banatre. and F. Ployette C o n s t r u c u o n of a Distributed System Supporting A t o m i c Transactions In Proceedings of the 3rd Symposium on Reliabihty in Distributed Software a n d D a t a b a s e Systems. October. 1983.
System R": Bruce G Lindsay. L a u r a M. Haas. C. Mohan. Paul F. Wilms. and R o b e r t A. Yost
C o m p u t a t i o n and C o m m u n i c a t i o n in R ' : A Distributed D a t a b a s e Manager. A C M Transactions on C o m p u t e r Systems 2(1):24-38. F e b r u a r y. 198:t.
TABS: Alfred Z. Spector. J a c o b Butcher. Dean S. Darnels. Daniel J D u c h a m p J e f f r e y L.
Eppinger. Charles E. Fineman. A b d e l s a l a m H e d d a y a. Peter M. Schwarz. Support for Distributed Transactions in the TABS P r o t o t y p e. In Proceedings of the F o u r t h S y m p o s i u m on Reliabihty in Distr.buted Software and D a t a b a s e Systems. pages 186-206. October, 198-4. Also available as Carnegie-Mellon R e p o r t C M U - C S - 8 ~ - 1 3 2. July 1984.
Boblingen Operating System: Hans Diel. G e r a l d Kreisslg. N o r b e t Lenz. Michael Scheib!e. and Bernd
Schoener. Data M a n a g e m e n t Facihues of an Operating System Kernel. In Sigmc,d '80,. pages 58-69. June. 1984.
Alfred Specror
Sessmn ?.loderator
