Lab 3: Transactions

Due Date: 10/23/2015
Please work in groups of two.

For Lab #3 you are asked to extend KVStore and KVClient to implement serializable ACID transactions using two-phase locking (2PL) and two-phase commit (2PC). Each transaction executes within a single application actor that is a client of KVStore (e.g., within a RingServer). So transactions are serial within each client actor, but multiple client actors may execute transactions concurrently.

We continue to assume that KVStore actors do not fail. Given that assumption, the D property is easy: no changes to the storage scheme are required to make transactions "durable". Also, this assumption makes 2PC easier, because it is unnecessary to deal with failure of a transaction participant.

Your transaction implementation should use the client-side caches implemented in KVClient, and it must keep the caches consistent.

Here are a few points to consider as you design your implementation.

You will want to add a begin/commit/abort API to KVClient, and also add unique transaction IDs and commit/abort messages to the KVStore messaging interface.
Given these extensions, it will be simplest to handle locking and conflict detection at the granularity of individual keys within the KVStore servers. If a transaction T1 requests a get/put for a key K, and then another transaction T2 requests a conflicting get or put for K before T1 completes (commits or aborts), your KVStore actors can and should detect this case and handle it.
If you handle this conflicting access scenario by blocking T2 until T1 completes, then you must address the problem of deadlock. For example, if T1 requests K1 and T2 requests K2, and then T1 requests K2 and T2 requests K1, neither T1 nor T2 can make progress.
You must address the problem of a failed or partitioned client. If a client loses contact with a server for longer than some fixed timeout, its pending transaction must be forced to abort.

Implement some tests to demonstrate that your transaction service is correct.

Note: You may find useful to use Akka schedulers to manage sessions (http://doc.akka.io/docs/akka/snapshot/scala/scheduler.html). The scheduler allows you to schedule a message to be sent to an actor at a specified time or after a specified delay.