deletions | additions       diff --git a/untitled.tex b/untitled.tex  index 12d81b5..b401922 100644  --- a/untitled.tex  +++ b/untitled.tex 
...
\textbf{Postgres-R} \cite{postgres-r} uses an eager replication model and group communication. It is implemented as an extension to PostgreSQL v6.4 \cite{postgres}. It tries to reduce messages and synchronization overhead by bundling writes into a single write set message using shadow copies to perform updates. As most replication protocols, it applies the read-one/write all approach using localized reads and pre-orders transactions to ensure order semantics guaranteeing that all nodes receive the writes sets in exactly the same order.   An important result extracted from \cite{postgres-r} is the insight that the distribution of full SQL update statements, as often done in eager update-everywhere approaches, is not optimal. Performance can be significantly improved by executing SQL statements only once and then propagating the resulting database changes (writesets) to other replicas.  Postgres-R has no centralized components and load balancing is left to the clients. This can become a problem in case of bursts of update traffic, since the system is busy resolving conflicts between the replicas.  Another shortcoming of Postgres-R is that it has a rather intrusive implementation, requiring modifications to the underlying database, something that is not always feasible and limits database heterogeneity. (As pointed out in \cite{fp462-cecchet} \cite{Cecchet_2008}  \textbf{Middle-R} was developed to alleviate these constraints, and implement Postgres-R functionality to the middleware). A solution to the problem of high conflict rates in group communication systems is to partition the load \cite{icdcs02-Jimenez}. In this approach however, update transactions cannot be executed on every replica. Clients have to predeclare for every transaction which elements in the database will be updated (so called \textit{conflict classes}). Depending on this set of conflict classes, a \textit{compound conflict class} can be deduced. Every possible compound conflict class is statically assigned to a replica; replicas are said to act as \texti{master site} for assigned classes. Incoming update transactions are broadcasted to all replicas using group communication, leading to a total order. Each replica decides then if it is the master site for a given transaction. Master sites execute transactions, other sites just install the resulting writesets, using the derived total order.  
...
Hihooi's design, proves to be flexible enough and allows clients to choose between the available transaction isolation levels provided by the underlying databases by setting the SET_TRANSACTION parameter before each START_TRANSACTION request.  In the context of \cite{Cecchet-2008} \cite{Cecchet_2008}  Hihooi uses a master-slave replication protocol, query interception at the JDBC driver, query-level load balancing, and statement replication. More recent research in database replication includes Megastore \cite{megastore}, Calvin \cite{Thomson_2012}, and Spanner\cite{Corbett_2013}. Although these works focus on orders of magnitude bigger data scales (while Hihooi focuses on scaling the workload), we mention them for completeness.  Google's \textbf{Megastore} uses fine-grained partiotioning of data and offers high availability and serializable ACID semantics, through syncronous replication, but transactions are limited to small subsets of the database.