Project Part 2: Concurrency, Commit Protocols

Start date 23 February, due 13 March.

For phase two of the project, you will work in pairs. One team member will implement concurrency control, the other will implement a commit protocol. You can use either of your code bases as the starting point. You will need to come to some agreement on how you will make use of the underlying transaction mechanisms, as what makes it easy for one task could make it hard for the other. You may choose to use multiple transactions running at each site, but you may not use transaction naming to get the underlying DBMS to manage transactions across sites.

Concurrency Control

You can implement whatever concurrency control mechanism you think best - 2-phase locking, timestamp ordering, shadow pages, or whatever you choose. You should support at least row-level concurrency. You can augment the database itself (e.g., put timestamps on rows) if that makes it easier - as long as such additional information is stripped before data is presented (this can easily be done as part of queries.) You must support at least the following:

1. Demonstrate that two transactions entered in a non-serializable order will somehow be delayed, aborted, or otherwise managed so the outcome is equivalent to some serial ordering.
2. Demonstrate that two transactions operating on the same tables, but different rows, can execute concurrently.
3. Demonstrate that you handle read/write conflicts as well as write/write conflicts.
4. Prove that your scheme will not block indefinitely. I.e., if you have a deadlock, you must detect and correct for it.

You may find that there are things that you don't handle well. As long as you demonstrate the above, it is okay if there are some things you can't handle - as long as you are aware of (and document) the conditions under which your concurrency control fails.

Distributed Failure/Recovery

This part of the project requires that you implement a distributed commit protocol, and demonstrate that you get correct results in spite of failure. You must support failure of any single site (including the one where the transaction is being entered). Any transactions running at the time must either abort or complete (including at the failed site when it recovers.) You may use the recovery mechanisms of the underlying databases, provided that this is independent for the separate tables (as with concurrency control above.) You need not crash the underlying DBMS - this can be simulated by having it abort any uncommitted transaction when a client (your server) crashes. You must demonstrate:

1. Correct recovery after a commit, to all sites having update.
2. Correct recovery before a commit: transaction must be aborted at all sites.
3. At least some situations where failure is non-blocking (remaining sites can run transactions that do not involve the failed sites.)

Your system does not need to be non-blocking in all cases, but you should document failures that can result in blocking or conditions that can result in an inconsistent database (hopefully you will have none of the above.)

For more details see the writeup for Project 1.

Turning in the assignment

You will turn in this assignment by demoing it to me, along with a brief code walkthrough. Also upload a tar file with the code (just source and instructions on how to run - not binaries/etc.) to Blackboard Please email the possible times for an appointment by 3/5 - 30 minutes sometime between 11:30 and 17:00 on 3/13.