Abstract: We describe applications of a virtually synchro-nous environment for distributed programming, which underlies a collection of distributed programming tools in the 1SIS2 system. A virtually synchronous environment allows processes to be structured into process groups, and makes events like broadcasts to the group as an entity, group membership changes, and even migration of an activity from one place to another appear to occur instan-taneously-- in other words, synchronously. A major advantage to this approach is that many aspects of a dis-tributed application can be treated independently without compromising correctness. Moreover, user code that is designed as if the system were synchronous can often be executed concurrently. We argue that this approach to building distributed and fault-tolerant software is more straightforward, more flexible, and more likely to yield correct solutions than alternative approaches. 1. A toolkit for distributed systems Consider the design of a distributed system for factory automation, say for VLSI chip fabrication. Such a system would need to group control 'processes into services responsible for different aspects of the fabrication procedure. One service might accept batches of chips needing photographic emulsions, another oversee transport of chips from station to sta-tion, etc. Within a service, algorithms would be needed for scheduling work, replicating data, coordi-

Data in real-time databases has to be logically consistent as well as temporally consistent. The latter arises from the need to preserve the temporal validity of data items that reflect the state of the environment that is being controlled by the system. Some of the timing constraints on the transactions that process real-time data come from this need. These constraints, in turn, necessitate time-cognizant transaction processing so that transactions can be processed to meet their deadlines. This paper explores the issues in real-time database systems and presents an overview of the state of the art. After introducing the characteristics of data and transactions in real-time databases, we discuss issues that relate to the processing of time-constrained transactions. Specifically, we examine different approaches to resolving contention over data and processing resources. We also explore the problems of recovery, managing I/O, and handling overloads. Real-time databases have the potential...

Transactional memory (TM) simplifies parallel programming by guaranteeing that transactions appear to execute atomically and in isolation. Implementing these properties includes providing data version management for the simultaneous storage of both new (visible if the transaction commits) and old (retained if the transaction aborts) values. Most (hardware) TM systems leave old values “in place” (the target memory address) and buffer new values elsewhere until commit. This makes aborts fast, but penalizes (the much more frequent) commits. In this paper, we present a new implementation of transactional memory, Log-based Transactional Memory (LogTM), that makes commits fast by storing old values to a per-thread log in cacheable virtual memory and storing new values in place. LogTM makes two additional contributions. First, LogTM extends a MOESI directory protocol to enable both fast conflict detection on evicted blocks and fast commit (using lazy cleanup). Second, LogTM handles aborts in (library) software with little performance penalty. Evaluations running micro- and SPLASH-2 benchmarks on a 32way multiprocessor support our decision to optimize for commit by showing that only 1-2 % of transactions abort. 1.

Concurrency control has been thoroughly studied in the context of traditional database applications such as banking and airline reservations systems. There are relatively few studies, however, that address the concurrency control issues of advanced database applications such as CAD/CAM and software development environments. The

An approach to the coordinated sharing and interchange of computerized information is described emphasizing partial, controlled sharing among autonomous databases. Office information systems provide a particularly appropriate context for this type of information sharing and exchange. A federated database architecture is described in which a collection of independent database systems are united into a loosely coupled federation in order to share and exchange information. A federation consists of components (of which there may be any number) and a single federal dictionary. The components represent individual users, applications, workstations, or other components in an office information system. The federal dictionary is a specialized component that maintains the topology of the federation and oversees the entry of new components. Each component in the federation controls its interactions with other components by means of an export schema and an import schema. The export schema specifies the information that a component will share with other components, while the import schema specifies the nonlocal information that a component wishes to manipulate. The federated architecture provides mechanisms for sharing data, for sharing transactions (via message types) for combining information from several components, and for coordinating activities among autonomous components (via negotiation). A prototype implementation of the federated database mechanism is currently operational on an experimental basis.

, Exception, Clock, Externalg Granularity ae fMember, Subset, Setg Type ae fPrimitive, Composite g Operators ae for, and, seq, closure, times, not g Consumption mode ae fRecent, Chronicle, Cumulative, Continuous g Role 2 fMandatory, Optional, Noneg Condition Role 2 fMandatory, Optional, Noneg Context ae fDB T , BindE , DBE , DBC g Action Options ae fStructure Operation, Behavior Invocation, Update-Rules, Abort Inform, External, Do Instead g Context ae fDB T , BindE , BindC , DBE , DBC , DBA g ---behavior invocation, in which case the event is raised by the execution of some user-defined operation (e.g. the message display is sent to an object of type widget). It is common for event languages to allow events to be raised before or after an operation has been executed. ---transaction, in which case the event is raised by transaction commands (e.g. abort, commit, begin-transaction) ---abstract or user-defined, in which case a programming mechanism is used that allows an appli...

Introduction This chapter gives an overview on multilevel transactions and its generalization toward open nested transactions. The main features of these transaction models are the following: first, semantic properties of operations can be exploited to relax the isolation of concurrent transactions; second, as a consequence, atomicity is achieved by compensation rather than state-based undo; and third, subtransactions can be made persistent independently of their commit state, that is, global visibility of their updates. Advanced transaction models and new correctness criteria for transaction executions have been proposed for the following reasons (and possibly further reasons that are not mentioned here): 1. to provide better support for long-lived activities in advanced DBMS applications, 2. to relax the classical ACID paradigm, for example, provide more flexibility as to when updates are made visible to concurrent transactions, 3. to support cooperation between the members

Abstract not found

Recoverable virtual memory refers to regions of a virtual This combination of circumstances is most likely to be found in situations involving the meta-data of storage address space on which transactional guarantees are repositories. Thus RVM can benefit a wide range of offered. This paper describes RVM, an efficient, portable, applications from distributed file systems and databases, to and easily used implementation of recoverable virtual object-oriented repositories, CAD tools, and CASE tools. memory for Unix environments. A unique characteristic RVM can also provide runtime support for persistent of RVM is that it allows independent control over the programming languages. Since RVM allows independent transactional properties of atomicity, permanence, and serializability. This leads to considerable flexibility in the use of RVM, potentially enlarging the range of applications than can benefit from transactions. It also control over the basic transactional properties of atomicity,

ACTA is a comprehensive transaction framework that facilitates the formal description of properties of extended transaction models. Specifically, using ACTA, one can specify and reason about (1) the effects of transactions on objects and (2) the interactions between transactions. This paper presents ACTA as a tool for the synthesis of extended transaction models, one which supports the development and analysis of new extended transaction models in a systematic manner. Here, this is demonstrated by deriving new transaction definitions (1) by modifying the specifications of existing transaction models, (2) by combining the specifications of existing models and (3) by starting from first principles. To exemplify the first, new models are synthesized from atomic transactions and join transactions. To illustrate the second, we synthesize a model that combines aspects of the nested and split transaction models. We demonstrate the latter by deriving the specification of an open nested transa...