Replicating backend for AcidState.

[Lemmih]

 AcidState is a high performance library for adding ACID ( http://en.wikipedia.org/wiki/ACID) guarantees to (nearly) any kind of Haskell data structure. In layman's term, it's a library that will make your data persist even in the event of, say, a power outage.

 AcidState relies on an on-disk transaction log from which to recreate the Haskell data structure if your application crashed unexpectedly. This makes the hard drive a single point of failure (leading to the loss of data, even) and the low reliability of hard drives simply does not merit this.

I propose that this should be solved by replicating the state across a cluster of machines. Each machine would keep a copy of the transaction log on disk and the single point of failure would be gone.

When thinking about this project, one has to keep the CAP theorem ( http://en.wikipedia.org/wiki/CAP_theorem) in mind. In particular, I propose consistency and availability to be guaranteed. Partition tolerance (compared to consistency and availability) has fewer uses and is much harder to implement.

 AcidState is already structured for multiple backends so few, if any, internal changes are required before this project can begin.

Interested mentors:

• Jeremy Shaw (an officially accepted haskell.org mentor)

Interested students:

• David Himmelstrup.

[gbaz]

A slight conceptual problem. see here:  http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/

You can't not have P. Partitions will happen. The question is when they do happen, do you lose consistency or do you lose availability? A well designed system can actually give the user the choice. Otherwise, I'd suggest privileging consistency by default, since we are talking about ACID state to begin with, and if users didn't care about the C, they might well want to use something weaker anyway.

[Lemmih]

You seem to be defining CAP somewhat differently from the wikipedia page. I want to lose availability in case of partitions.