Regular execution. We now describe transaction execution in absence of failures. In the description we refer to a coordinator, which is the site where the transaction is originated, and to participants the other sites where the transaction is executed. Note however that the description is easily generalizable to a client/server environment. In a client/server architecture, the client process calls several servers at various sites and then calls a system process for commit coordination; each server does its own logging. Our approach can be extended to such an architecture by assuming that the commit coordinator commits all available servers and that servers perform logging of reception vectors; the coordinator site is the site of the commit coordinator. 1. It is progressive: the coordinator can always commit, possibly with other sites. 2. It is non-blocking : each site can take unilateral decisions at each step of the algorithm, and as a result is never blocked. The coordinator site c executes all its reads locally. All writes are also executed locally, and they are transmitted to all other sites together with the reception vector entry for c, RV o[c]. On each write, a participant p compares this entry with its own entry for the coordinator site, RV o[c]. If the entries are equal, i.e., site p has executed all actions on o originated at c, p will execute the write. If the comparison fails for a write operation, p will abort the transaction locally and not accept any further write for this particular transaction. If p accepts a write on object o, it also updates its reception vector entry for site c, RV o [c], with the time of the write
Appears in 2 contracts
Sources: Independent Updates and Incremental Agreement in Replicated Databases, Independent Updates and Incremental Agreement in Replicated Databases
Regular execution. We now describe transaction execution in absence of failures. In the description we refer to a coordinator, which is the site where the transaction is originated, and to participants participants,1 the other sites where the transaction trans- action is executed. Note however that the description is easily generalizable to a client/server environment. In a client/server architecture, the client process calls several servers at various sites and then calls a system process for commit coordination; each server does its own logging. Our approach can be extended to such an architecture by assuming that the commit coordinator commits all available servers and that servers perform logging of reception vectors; the coordinator site is the site of the commit coordinator.
1. It is progressive: the coordinator can always commitcom- mit, possibly with other sites.
2. It is non-blocking : each site can take unilateral decisions at each step of the algorithm, and as a result is never blocked. The coordinator site c executes all its reads locally. All writes are also executed locally, and they are transmitted trans- mitted to all other sites together with the reception vector entry for c, RV o[c]. On each write, a participant partici- pant p compares this entry with its own entry for the coordinator site, RV o[c]. If the entries are equal, i.e., site p has executed all actions on o originated at c, p will execute the write. If the comparison fails for a write operation, p will abort the transaction locally and not accept any further write for this particular transaction. If p accepts a write on object o, it also updates its reception vector entry for site c, RV o [c], with the time of the writewrite action. At the end of a transaction, the coordinator forces2 all log records together with the commit record; this causes the atomic, independent commit at the coor- dinator site.3 The coordinator then sends its decision to all other sites. Each site that has fully partici- pated in the transaction (i.e., has accepted all writes), commits upon receipt of the coordinator's decision, by forcing all log records in the log together with the commit record. It then sends a message to the co- ordinator indicating the commitment has been suc- cessfully executed. Given that the decision to commit
1 The description is easily generalizable to a client/server en-
Appears in 1 contract
Sources: Independent Updates and Incremental Agreement in Replicated Databases