This paper describes some preliminary results of the needs survey of real-time databases, performed in the RAPID

Abstract. A replicated data object is a typed object that is stored redundantly at multiple locations in a distributed system. Each of the object’s operations has a set of quorums, which are sets of sites whose cooperation is needed to execute that operation. A quorum assignment associates each operation with its set of quorums. An operation’s quorums determine its availability, and the constraints governing an object’s quorum assignments determine the range of availability properties realizable by replication. In this paper, the restrictions on quorum assignment imposed by three kinds of atomicity mechanisms found in the literature are analyzed: (1) serial schemes, in which replication and atomicity are implemented independently at different levels in the system, (2) static schemes, in which the transaction serialization order is predetermined, and (3) hybrid schemes in which the serialization order emerges dynamically. The following results are derived: (1) Although serial schemes place the strongest restrictions on concurrency, they place the weakest restrictions on availability. (2) Although hybrid and static mecha-nisms place incomparable restrictions on concurrency, hybrid mechanisms place weaker restrictions on availability. (3) Bounding the maximum depth of transaction nesting strengthens restrictions on concurrency for all classes, but weakens restrictions on availability for hybrid schemes only. Concurrency and availability are best considered as dual properties: A complete analysis of an atomicity mechanism should take both into account.

This report documents the achieved results of the first year. Section 2 provides an overview over the objectives of the work packages for the first year and their completion state. Sections 3-7 present the results in detail.

When users work on data replicated on several machines, the data may be inconsistent if updates are not controlled by some protocol. One class of protocols that handles this is called atomic commit protocols (ACP). The two-phase commit (2PC) protocol is a well-known, simple and elegant ACP. In the future it is expected that the machines containing replicated data may be portable, and therefore often disconnected from the network for arbitrary amounts of time. Then we will need an asynchronous 2PC protocol that does not rely on any assumptions about message delays. This report describes the theory behind, the requirements to, the design and implementation of a proof-of-concept version of an asynchronous message delivery system and 2PC protocol for the New File Repository, a distributed storage architecture.

this paper we show that such dynamic algorithms can be obtained simply by letting transaction update the directory

Abstract. This paper describes, for the case of Enterprise Java Bean components and JBoss application server, how replication for availability can be supported to tolerate application server/transaction manager failures. Replicating the state associated with the progression of a transaction (i.e., which phase of two-phase commit is enacted and the transactional resources involved) provides an opportunity to continue a transaction using a backup transaction manager if the transaction manager of the primary fails. Existing application servers do not support this functionality. The paper discusses the techical issues involved and shows how a solution can be engineered.

An early recovery protocol that was investigated at length and is currently implemented in most commercial Distributed Database Management System products is the two-phase commit protocol. However, there is one main drawback in using this, namely blocking, that is, operational sites having to wait for the recovery of a failed site in order to complete a transaction. The two-phase commit protocol continues to be implemented in commercial Distributed Database Management System products even though alternatives to it have been developed to alleviate the blocking drawback. The alternatives are the three-phase commit protocol and a vendor developed replication technology. A critical and systematic analysis of these recovery protocols was conducted to determine the justification for continuing to implement the two-phase commit protocol in current commercial Distributed Database Management System products. This paper will present the results of the critical analysis. 1.

"From a certain point onward there is no longer any turning back. That is the point that must be reached." Kafka Protocols that allow operational sites to continue transaction processing even though site failures have occurred are called nonblocking. Many applications require nonblocking Qrotocols. This paper investigates the properties of nonblocking protocols. Necessary and sufficient conditions for a protocol to be nonblocking are presented and from these conditions a method for designing them is derived. Both a central site nonblocking protocol and a decentralized nonblocking protocol are presented.

Abstract—Three-tier middleware architecture is commonly used for hosting enterprise-distributed applications. Typically, the application is decomposed into three layers: front end, middle tier, and back end. Front end (“Web server”) is responsible for handling user interactions and acts as a client of the middle tier, while back end provides storage facilities for applications. Middle tier (“Application server”) is usually the place where all computations are performed. One of the benefits of this architecture is that it allows flexible management of a cluster of computers for performance and scalability; further, availability measures, such as replication, can be introduced in each tier in an application-specific manner. However, incorporation of availability measures in a multitier system poses challenging system design problems of integrating open, nonproprietary solutions to transparent failover, exactly once execution of client requests, nonblocking transaction processing, and an ability to work with clusters. This paper describes how replication for availability can be incorporated within the middle and back-end tiers, meeting all these challenges. This paper develops an approach that requires enhancements to the middle tier only for supporting replication of both the middleware back-end tiers. The design, implementation, and performance evaluation of such a middle-tier-based replication scheme for multidatabase transactions on a widely deployed open source application server (JBoss) are presented.