Dean S. Daniels, Alfred Z. Spector, and Dean S. Thompson. Distributed logging for transaction processing. In A CM pecial Interest Group on Management of Data 1937 Annual Conference, pages 82-96, ACM SIGMOD, May 1987.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....in common. Each OM manages a set of persistent objects, storing the state of each object in stable storage. Normally, an OM s stable storage will be provided by the node where the OM is running. There are other possibilities; for example, stable storage might be provided as a network service [Daniels et al. 1987, Cohen 1989] An object O managed by object manager OM X has an identifier, id(O) that is unique across all object managers. A typical approach is to form id(O) from id(OM X) and an additional identifier that is unique within OM X. Associated with each object identifier is a version of the ....

Dean S. Daniels, Alfred Z. Spector, and Dean S. Thompson. Distributed logging for transaction processing. In A CM pecial Interest Group on Management of Data 1937 Annual Conference, pages 82-96, ACM SIGMOD, May 1987.

....mechanism supports both kinds of systems. Some servers are resilient: they survive failures of their node. Resilience requires access to a non volatile storage medium. The storage need not be located at the server s node; instead it could be provided over the network by a stable storage service [7]. Every node has a clock. As mentioned, we assume that the nodes clocks are loosely synchronized with some skew ; nodes ensure this by carrying out a clock synchronization protocol periodically. At least one practical clock synchronization protocol exists [2] It synchronizes clocks of nodes on ....

Daniels, D. $., Spector, A. Z., and Thompson, D.S. Distributed Logging for Transaction Processing. ACM Special Interest Group on Management of Data 1987 Annual Conference, ACM SlGMOD, May, 1987, pp. 82-96.

....21 4. Related Work . 25 5. Application Example . 26 5.1 Finite state machine . 27 5.2 Restart . 28 6. Current implementation status and possible extensions ....

....26 5.1 Finite state machine . 27 5.2 Restart . 28 6. Current implementation status and possible extensions . 29 7. Conclusion . 32 8. References ....

[Article contains additional citation context not shown here]

D. Daniels : "Distributed Logging for Transaction Processing", PhD Thesis, CMU-CS-89-114 Pittsburgh, Pensylvania, Dec. 1988

....120 The simulation results presented in this thesis quantitatively demonstrate XEL s effectiveness for a wide variety of applications and illustrate its strengths and weaknesses compared to the traditional FW method. 7.3 Extensions 7.3. 1 Non volatile Region of Main Memory Previous authors [15, 13, 39, 9, 53] have proposed system designs in which some (but not all) of main memory is non volatile. Battery backup to some portions of RAM ensures that the contents will not be lost if the regular power supply is interrupted. In such a system, parallel XEL can greatly reduce the disk bandwidth required for ....

Dean S. Daniels, Alfred Z. Spector, and Dean S. Thompson. Distributed Logging for Transaction Processing. In Proc SIGMOD '87 Conf, pages 82--96, San Francisco, California, May 1987.

....the type of records and their structure and therefore has no problem following pointers. In general purpose logging systems, two major problems arise for the implementation of automatic obsolete record detection: ffl The roots are not known by the logging system. For instance in Camelot DLF [Daniels 88] a logging system for transaction recovery, there are three kinds of record: checkpoints, records from committed transactions and records from aborted ones. The first two kinds are the roots. The logging system which is quite dedicated is able to recognise checkpoints from other records; but it ....

Dean Spencer Daniels: "Distributed Logging for Transaction Processing". PhD Thesis, CarnegieMellon Univ., Pittsburgh, PA (USA), Tech. Rep. CMUCS -89-114. Dec. 1988.

....commitment [1] recovery protocols [2] and concurrency control [3] need reliable logs. Thus, a logging service is a basic tool for reliability in distributed systems [4, 5] Moreover, an increasing number of applications implement logs customized to their specific needs. As examples, Camelot [6], QuickSilver [7] and Isis [8] use logs for transactions management and failure recovery. Emacs uses an in memory log to undo and redo file modifications. Instant Replay [9] uses a log to replay debugging sessions. Sprite [10] stores its complete Author s other affiliation: Laboratoire MASI, ....

....Multiple client logical logs are multiplexed and replicated over multiple physical logs, i.e. storage media, also presenting the same semantics. For clients 1 , a logical log is represented by an unique log identifier (Lid) The pair (Lid, Rid) is similar to the Log Sequence Numbers of Camelot [6] or Quicksilver [4] A client may use multiple logs. A physical or logical log may be shared between processes. Records from different logical logs can be multiplexed on a physical log. 3 Requirements The logs of different existing applications present several different features. The differences ....

[Article contains additional citation context not shown here]

D. S. Daniels, Distributed Logging for Transaction Processing. PhD thesis, Carnegie-Mellon University, Pittsburgh PA (USA), Dec. 1989. Available as Tech. Report CMU-CS-89-114.

....of all files in use replace the current ones. In the current version of STAR, we consider that files are not shared. The management of shared files is a complex problem, and requires a distributed database manager. A future extension would integrate an existing and open log manager as Camelot [8], Clio [10] or KitLog [20] The file manager is implemented as a set of file servers. A file server is associated with each copy. The file functions of the user s library coordinate accesses to file servers to keep the consistency property. 6. Performances In this section, we present the ....

D.S. Daniels. Distributed Logging for Transaction Processing. PhD Thesis, Technical Report CMU-CS-89114, Carnegie-Mellon University, Pittsburg, PA (USA), December 1988.

....is used for updating objects or files by atomically transferring their new created versions to permanent storage [4] 9] Dependent on the application area, logs are used together with different representations of secondary, non volatile storage architectures. In transaction processing systems [1][6][23] usually data bases are used as permanent data repository. For many applications, where communication takes place via explicit message transmission, permanent data is stored in file systems [15] 29] 30. In systems supporting distributed data replication logging is used to maintain the ....

....different independent resource managers. A set of so called log file groups are provided each of them supporting another level of reliability. Each resource manager is assigned a certain log file group which accomplishes the reliability requirements of that particular resource manager. In Camelot [6] a distributed logging service is designed and implemented that facilitates transaction recovery. The logging service uses distributed replication to achieve high availability and high reliability of the log records. In Camelot the log is distributed on several nodes, each node having a part of ....

[Article contains additional citation context not shown here]

D. Daniels : "Distributed Logging for Transaction Processing", PhD Thesis, CMU-CS-89-114 Pittsburgh, Pensylvania, Dec. 1988

....is full, it applies the modifications logged in NVRAM to the directories stored on disk. Because NVRAM is a reliable medium, this implementation provides the same degree of fault tolerance as the other implementations, while the performance is much better. A similar optimization has been used in [24, 30, 31, 32]. Using NVRAM, some sequences of directory operations do not require any disk operations at all. Consider the use of tmp. A file written in tmp is often deleted shortly after it is used. If the append operation is still logged in NVRAM when the delete is performed, then both the append and ....

D.S. Daniels, A.Z. Spector, and D.S. Thompson, "Distributed Logging for Transaction Processing," Proc. ACM SIGMOD 1987 Annual Conference, San Francisco, CA, pp. 82-96 (May 1987).

....handled by the B tree data structure, since there is little I O as the B tree grows consistently to the right; indeed this is 13 the basic situation in which a B tree load takes place. There are a number of other proposed structures to deal with indexing log records by ever increasing value [8]. In [21] the effective depth of a B tree, symbolized by D e , was defined to be the average number of pages not found in buffer during a random key value search down the directory levels of a B tree. For B trees of the size used to index Account ID Timestamp in Example 1.2, the value for D e is ....

Dean S. Daniels, Alfred Z. Spector and Dean S. Thompson, "Distributed Logging for Transaction Processing", ACM SIGMOD Transactions, 1987, pp. 82-96.

....every DM. The only requirement is that the DMs in the new transactions must have acknowledged the coordinator s most recent crash. 7.5 Related Work In this section we survey related work on log servers, DWAL protocols, and crash recovery algorithms in parallel logging environments. Daniels et al. [6] discuss the cost, performance, survivability, and operational advantages of shared logging facilities for distributed transaction processing. Their design, which lets several log servers operate in parallel, can replicate log data across multiple servers to improve log availability. A single log ....

D. S. Daniels, A. Z. Spector, and D. S. Thompson. Distributed logging for transaction processing. In Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data, pages 82--96, May 1987.

....systems are referred to as client server DBMSs. Recovery has long been studied in centralized and distributed database systems [Gray78, Lind79, Gray81, Moha90, BHG87, GR92] and more recently in architectures such as shared disk systems [MN91, Lome90, Rahm91] and distributed transaction facilities [DST87, HMSC88]. However, little has been published about recovery issues for client server database systems. This paper describes the implementation challenges and performance tradeoffs involved in implementing recovery in such a system, based on our experience in building the client server implementation of ....

....client server system) to perform Redo for a failed node. 6.3. Recovery in Distributed Transaction Facilities Recovery is also a concern in systems which provide general transaction support in a network computing environment. These systems include the distributed logging facility of CMU s Camelot [DST87] and IBM Almaden s QuickSilver system [HMSC88] Both are intended to run in a hardware environment similar to the one for which ESM CS was designed. However, both of these systems have fundamentally different software architectures than ESM CS. These systems attempt to shield clients from the ....

Daniels, D., Spector, A., Thompson, D., "Distributed Logging for Transaction Processing", Proc. ACM SIGMOD Int'l Conf. on Management of Data, San Francisco, May, 1987.

....a new image of the directory by replaying missed operations. Finally, the last phase unlocks the replicas. The old records of a logical log are removed after reconciliation if all the servers having a copy of the directory were involved in the reconciliation. 6. 2 Camelot Camelot logging facility [Daniels et al. 1987, Daniels 1988] is a distributed logging service designed for transaction recovery. The clients of the service are recovery managers. The Camelot log records are replicated for reliability and availability. For a given logical log, each record is replicated on W log servers (on different sites) ....

....1992a, Ruffin 1992b] the fixed overhead is of 24 bytes per record. The space overhead for locating records is difficult to measure as it depends of the whole physical log organization. It may be reduced when the logging system is designed for a particular application, as Sprite LFS, or in Camelot [Daniels et al. 1987, Daniels 1988] where the log is designed for transactions. In fact, only a small amount of data is needed to find records. Generally the physical log may be read sequentially backward or forward to find a particular record. Additional information may be added to the log to accelerate this seek. ....

[Article contains additional citation context not shown here]

Daniels, D. S., Spector, A. Z., and Thompson, D. S. 1987. Distributed Logging for Transaction Processing. Proc. of the ACM Special Interest Group on Mgt. of Data, San Francisco, CA (USA). 27-29 May. SIGMOD Record, Vol. 16, N ffi 3, pp. 82--96. Dec.

....by replaying missed operations. Finally, the last phase unlocks the replicas. The old records of a logical log are removed after reconciliation if all the servers having a copy of the directory were involved in the reconciliation. 6. 2 Camelot Camelot logging facility [Daniels et al. 1987, Daniels 1988] is a distributed logging service designed for transaction recovery. The clients of the service are recovery managers. The Camelot log records are replicated for reliability and availability. For a given logical log, each record is replicated on W log servers (on different sites) among N. At ....

.... records, from meta data for physical log management (e.g. to find the end of the log and for compaction) The former generates a per record fixed overhead, whereas the latter tends to be proportional to the physical log size as it is shown by a lot of existing logging implementation: Camelot [Daniels 1988], Clio [Finlayson 1989] Sprite LFS [Rosenblum and Ousterhout 1991] and K I T L O G [Ruffin 1992a] In all these systems, the size of meta dataneeded to find records depends on the cost (in time) that the system is ready to afford for record lookup. Moreover, the log reliability induces an ....

[Article contains additional citation context not shown here]

Daniels, D. S. 1988. Distributed Logging for Transaction Processing. PhD Thesis, Carnegie-Mellon University, Pittsburgh, PA (USA), Technical Report CMU-CS-89114. Dec.

....contents during restart by scanning the log only once and only forward. 1. Introduction Logs are an important facility for fault tolerant distributed systems since they allow to reliably store information that is needed to provide a global consistent system state also in the presence of failures [1][2] 7] A log is a piece of stable storage that survives the complete crash of a node in a distributed system and can tolerate media faults. Logically, the log represents an append only sequence of unstructured records needed to redo past actions or to correct the loss of consistency due to ....

....simply by checkpointing the log table, i.e. transferring the contents of the log table to a separate log partition as described in Fig. 3. new log partition log record non volatile memory buffer volatile memory log table old log partition Fig. 3 : log compression Compared to existing Log Services [1][2] 7] our approach to realize the compression phase turns out to be very efficient because of the following two aspects : Elsewhere, a Log Service is not able to distinguish between obsolete and relevant log records, since it does not get the knowledge to interpret the semantics of the log ....

D. Daniels : "Distributed Logging for Transaction Processing", PhD Thesis, CMU-CS-89-114 Pittsburgh, Pensylvania, December 1988

....due to the diversity of the systems which have been designed for various purposes. The logging systems studied are: Clio [Finlayson and Cheriton 1987, Finlayson 1989] a logging service dedicated to file systemimplementationbut general enough to be used for other logging purposes; Camelot DLF [Daniels et al. 1987, Daniels 1988] a logging service designed for transactions; K I T L O G [Ruffin This work was partly supported by grant number ERBCHBGCT92009 of the HCM European Union program at the University of Glasgow and partly by Esprit Basic Research Action Broadcast 6360 at INRIA. 1992a, Ruffin ....

....all the records of a single logical log. 2 Overview of the systems studied This section presents the main characteristics of the four systems studied as well as their record and logical log units and their interfaces. 2. 1 Overview of Camelot DLF The Camelot Distributed Logging Facility (DLF) [Daniels et al. 1987, Daniels 1988] is a logging service designed for transaction processing [Spector 1987] The service clients are recovery managers. One Camelot s distinguishing characteristics is its replication algorithm. Log records are replicated for reliability and availability. Suppose there are N log ....

DANIELS, D. S., SPECTOR, A. Z., AND THOMPSON, D. S. 1987. Distributed Logging for Transaction Processing. Proc. of the ACM SIGMOD Int. Conf., San Francisco, CA (USA). 27-29 May. SIGMOD Record, Vol. 16, N ffi 3, pp. 82--96. Dec.

....of the systems which have been designed for various purposes. The logging systems studied are: Clio [Finlayson and Cheriton 1987, Finlayson 1989] a logging service dedicated to file systemimplementationbut general enough to be used for other logging purposes; Camelot DLF [Daniels et al. 1987, Daniels 1988], a logging service designed for transactions; K I T L O G [Ruffin This work was partly supported by grant number ERBCHBGCT92009 of the HCM European Union program at the University of Glasgow and partly by Esprit Basic Research Action Broadcast 6360 at INRIA. 1992a, Ruffin 1992b] a ....

....a single logical log. 2 Overview of the systems studied This section presents the main characteristics of the four systems studied as well as their record and logical log units and their interfaces. 2. 1 Overview of Camelot DLF The Camelot Distributed Logging Facility (DLF) Daniels et al. 1987, Daniels 1988] is a logging service designed for transaction processing [Spector 1987] The service clients are recovery managers. One Camelot s distinguishing characteristics is its replication algorithm. Log records are replicated for reliability and availability. Suppose there are N log servers on different ....

[Article contains additional citation context not shown here]

DANIELS, D. S. 1988. Distributed Logging for Transaction Processing. PhD Thesis, Carnegie-Mellon Univ., Pittsburgh, PA (USA), Tech. Rep. CMU-CS-89-114. Dec.

....use. When a process rolls back, old versions of files in use replace current ones. Shared files management has not been considered. Such management is complex, and requires a distributed database manager [5] Another extension would be to integrate an existing and open log manager, as in Camelot [12], Clio [17] or KitLog [30] 5 Process Allocation The process allocation in GATOSTAR is not limited to independent programs. It is mostly geared towards parallel applications and takes into account processes behavior. We present in this section an overview of a multicriteria load sharing ....

D.S. Daniels. Distributed Logging for Transaction Processing. PhD Thesis, Technical Report CMU-CS-89-114, Carnegie-Mellon University, Pittsburg, PA (USA), December 1988

No context found.

D. Daniels. Distributed Logging for Transaction Processing. PhD Thesis, Pittsburgh, 1988

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC