tpcOpRunnable in TPCMasterHandler

[tecnogram888]

acquire appropriate locks

*** FIgure out how this interfaces with the TPC Log

4 parts:

Init
Read
ABORT
COMMIT

[tecnogram888]

http://piazza.com/class#spring2012/cs162/760

[tecnogram888]

http://piazza.com/class#spring2012/cs162/686
In this project, we will do the following. There will be updates/notes if anything changes.

1. We are going to assume that we can figure out whether the op will succeed or fail before we actually try to do so. The way it remains, it will always succeed.

NOTE1: Ideally, the Slave should try to actually write to the Store (and Cache) to see whether it succeeded or failed. Then it would keep an undo log for that 2PC op. After receiving the global decision, the slave would then undo in case of a global abort. In this project, so far we have decided not to do an undo log.

1. The Master/Coordinator will wait until it received all ACK. If it times out, it will resend the global decision to the slaves it hasn't heard from. If the slave is dead, the connection will be broken. Master will then try to create a new connection until it can (i.e., the slave is restarted) and send the global decision. In this case, the awaken slave will find itself in a state where it doesn't know the global decision. So it will wait for master to send a global decision for the op it is in (the slave will know it is in, because it will see the READY message in its own log after coming back from dead.)

NOTE2: As you can see this makes each 2PC op a blocking call, and no other 2PC op will happen until this is resolved. This is to keep things simpler. Otherwise, we could create a separate thread in master (up to threadpool limit) and let those threads be the master of individual ops, which would've also allowed us to have parallel 2PC ops in general. Unfortunately, that would've made failure recovery and corresponding bookkeeping more complicated.