deletions | additions       diff --git a/untitled.tex b/untitled.tex  index a6292f5..785c073 100644  --- a/untitled.tex  +++ b/untitled.tex 
...
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.   All previous works suffer from a variety of problems. They either reduce response time by giving up consistency or enforce limitations via predeclaration of the access patterns or statically partitioned data. thus limiting scale-out possibility.  \textbf{Ganymed} \cite{ganymed-middleware2004} proposed a middleware solution that addresses all of the above and our work is heavily influenced by it. The main idea behind Ganymed is a transaction scheduling algorithm, called RSI-PC, that separates update and read-only transactions. Ganymed routes update transactions to a \textit{main} or \textit{primary} server and queries to a potentially unlimited number of read-only copies. An RSI-PC scheduler can be used with \testit{Snapshot Isolation} (as defined in \cite{Berenson_1995}) based databases as replicas that offer the transaction isolation levels \textit{Serializable} and \textit{Read Committed}. Update transactions are directly forwarded to the master. After successful commit, the scheduler makes sure the corresponding write set is sent to the replicas and that every replica applies the write sets of different transactions in the same order as the corresponding commit occurred on the master database. The scheduler uses also the notation of a global database version number, something similar to Hihooi's TRANS-SET. Read-only transactions can be processed by any replica; the scheduler is free to decide where. Ganymed choses a replica based on \textit{least pending transactions} number. If a chosen replica is not updated to the latest global version number, the scheduler must delay the creation of the read-only snapshot  Hihooi does not use write sets to propagate committed results to the replicas; instead it parses the SQL commands. Nevertheless, we feel this should be implemented in the future.  Hihooi  can support whatever isolation level the underlying database engine offersand  with appropriate changes in the Manager.  More recent research in database replication includes [] [] []. Although these works focus on ... , we review them briefly for context.