Transactional replication in a .NET environment

Abstract

Replikation als wichtiger Mechanismus in Erzielung von Zuverlässigkeit verteilter Systeme ist bereits umfangreicher Forschung unterlegt gewesen.<br />Verschiedene Ansätze die Erreichbarkeit während Systemdegradation (z.B.<br />Netzwerktrennung) zu verbessern haben sich traditionell auf pessimistische Replikationsprotokolle konzentriert, welche Update-konflikte während Degradation vermeiden. Vor kurzem wurde eine neue Klasse an optimistischen Replikationsprotokollen vorgestellt, die weniger restriktiv als pessimistische Protokolle ist und die es erlaubt, Erreichbarkeit und Konsistenz eines Systems auszubalancieren. Es können handelbare und nicht-handelbare Konsistenzbedingungen im System definiert werden, wobei die ersten während Systemdegradation gegen Erreichbarkeit gehandelt werden können.<br />Active Replication Per Partition Protocol (ARPPP) ist ein konkretes Replikationsprotokoll, das diese Balancierung anwendet. Es ist eine Modifikation der klassischen aktiven Replikation. In einem gesunden System fordert ARPPP strenge Konsistenz, also erlaubt keine Operation, die gegen eine beliebige Konsistenzbedingung stoßt. Im Falle eines Knotenausfalls oder einer Netzwerktrennung werden vorübergehend alle handelbaren Konsistenzbedingungen von ARPPP aufgehoben und somit alle Operationen, die keine nicht-handelbaren Bedingungen betreffen, erlaubt, auch wenn die handelbaren Bedingungen verletzt werden können. Nachdem das Netzwerk sowie alle Systemknoten heilen, wird strenge Konsistenz im System - während sogenannter Rekonciliation - wiederhergestellt.<br />Die Kontribution dieser Arbeit ist die Prototypimplementierung und -evaluierung des ARPPP Replikationsprotokolls unter Microsoft .NET in der C# Programmiersprache. Basierend auf Eigenschaften des .NET Frameworks 2.0, unterstützt der Prototyp sowohl Transaktionen, als auch geschachtelte Replikaaufrufe.<br />Die Ergebnisse der Evaluierung indizieren, dass der zusätzliche Bedarf an Überprüfen von Konsistenzbedingungen nicht nur einen höheren Aufwand mit sich bringt, sondern auch die Ursache für öftere Transaktionsabbrüche bei manchen gleichlaufenden Operationen ist. Dies ist jedoch das erwartete Verhalten, das auf den Bedarf einer sorgfältigen Definition von Konsistenzbedingungen in jeder Applikation verweist.<br />

Replication as an important mechanism in achieving dependability of distributed systems has already been subject to extensive research.<br />Approaches to improve availability in degraded situations (e.g. network partitions) traditionally focus on pessimistic replication protocols, which prevent update conflicts during degradation. Recently, a novel class of optimistic replication protocols has been introduced, which are less restrictive than pessimistic protocols and allow trading consistency against availability. Tradeable and non-tradeable constraints can be defined in the system, while the former will be traded against availability during degradation.<br />The Active Replication Per Partition Protocol (ARPPP) is one concrete protocol applying this trade-off. It is a modification of the standard active replication scheme. In a healthy system, the ARPPP enforces strict constraint consistency and thus does not allow operations violating any of the constraints defined in the system. In case of node failures or network partitions, the ARPPP temporarily relaxes tradeable constraints and allows all operations not affecting non-tradeable constraints, even though tradeable constraints might become violated. After the network and all nodes recover from failures, strict constraint consistency must be reestablished in a process called reconciliation.<br />The contribution of this thesis is a prototype implementation and evaluation of the ARPPP in the Microsoft .NET environment using the C# programming language. Based on the features of the .NET Framework 2.0, the prototype provides full transaction support and allows nested replica calls as well.<br />Evaluation results indicate, that the additional necessity of constraint checking not only causes additional overhead and thus decreases performance, but in some cases also imposes higher transaction abort rates of concurrent operations. This is, however, expected behaviour, that admonishes to a careful constraint definition at application development time.