Integration and Evaluation of Multi-Instance-Precommit Schemes within PostgreSQL * Paolo Romano and Francesco Quaglia DIS, Sapienza Universit` a di Roma Abstract Multi-Instance-Precommit (MIP) has been recently pre- sented as an innovative transaction management scheme in support of reliability for Atomic Transactions in multi- tier (e.g. Web-based) systems. With this scheme, fail-over of a previously activated transaction can be supported via simple retry logics, which do not require knowledge about whether, and on which sites, the original transaction was precommitted. Mutual deadlock between the original and the retried transaction are prevented via MIP facilities, which also support reconciliation mechanisms for at-most- once transaction execution semantic. All these features speed up fail-over, and avoid the overhead for high avail- ability of precommit logs across (geographically spread) middle-tier servers. In this article we present an extension of the open source PostgreSQL database system in order to support MIP. The extension is based on the exploitation of PostgreSQL’s native multi-version concurrency control scheme. Challenges encountered while implementing MIP within PostgreSQL are discussed. Finally, we present an experimental evaluation based on the TPC-W benchmark, aimed at quantifying the relative overhead of MIP facil- ities on transaction execution latency, system throughput and storage usage. 1 Introduction The design and development of supports for reliable transaction management in (Web-based) multi-tier dis- tributed systems is a fundamental issue for most modern ap- plications, such as e-business. One complex representative case is when middle-tier servers drive the execution of dis- tributed transactions involving multiple (autonomous) back- end sites, and one cannot rely on application level compen- sation mechanisms to guarantee atomicity despite failures. In this scenario, the employment of an Atomic Commit Pro- tocol (ACP) is mandatory, and the challenge is how to opti- mize the system behavior when the ACP is employed as the * This work makes use of results produced by the PI2S2 Project man- aged by the Consorzio COMETA, a project co-funded by the Italian Min- istry of University and Research (MIUR) within the Piano Operativo Nazionale ”Ricerca Scientifica, Sviluppo Tecnologico, Alta Formazione” (PON 2000-2006). building block for distributed transaction management. The mainstream ACP is the so called Two-Phase- Commit (2PC), which is based on the precommit state as the expression of transactional sites endorsement for suc- cessful execution of local data manipulation statements. For this protocol, several frameworks have been proposed in or- der to achieve integration with the multi-tier system orga- nization, among which we can mention classical Transac- tion Processing Monitors [2] and the recent e-Transaction specification [3]. The base idea in all these solutions is to achieve reliability via mutual fail-over capabilities across middle-tier server replicas or incarnations. This is done via diffusion of precommit/abort logs across the middle-tier (before any commit/abort message is really sent out) so to prevent that different server replicas can take different de- cisions on a same distributed transaction, possibly leading to a violation of the atomicity property. From a formal per- spective, this means having consensus on the outcome of the distributed transaction across the middle-tier. On the other hand, the cost for achieving consensus can become a dominating performance adverse factor in case of large scale geographical distribution of middle-tier servers, as in the case of Application Delivery Network (ADN) in- frastructures [10], namely representative expressions of the edge computing paradigm in service oriented applications. In order to cope with this issue, we have recently presented an innovative (application transparent) management model for distributed atomic transactions, which is referred to as Multi-Instance-Precommit (MIP) [7], which has been used as the building block for the construction of multi-tier reli- ability protocols framed by the e-Transaction specification. With MIP, each replicated middle-tier server instance can retry the execution of a given transaction (e.g. upon client re-transmission), without explicit knowledge (and therefore consensus) about the state of a previously acti- vated instance (if any) of that same transaction. At the same time, the two transaction instances do not incur mutual deadlock and are reconciliated at commit time just thanks to the capabilities offered by MIP, hence obeying at-most-once semantic. We note that avoidance of explicit consensus on transaction outcome across the middle-tier server means also avoiding the need for accurate failure detection capa- 1