4 ms·

One thing I didn’t quite catch was: I thought most write transactions needs consistent reads on many (contended) “objects”, but the actual writes are often just

• rawgabbit 3y ago
  You can take locks on all objects before you write. Most systems don’t do that. Usually there are multiple writes to complete a business process. In each step stale data is read to create a write request similar to how you place your order with the wait staff at the restaurant. The wait staff will orchestrate your request. First the chef prepares your meal according to the order ticket. Second the wait staff delivers your meal based on the chef’s internal work order. Lastly they take your payment based on the original order ticket. Notice there are at least three microtransactions based on stale data. No one is holding locks until the diner finishes eating.
  • zaphirplane 3y ago
    IIUC, That’s a micro service way, missing cancellations and rollback and timeouts What happens if the chef can’t fulfill the meal, the customer leaves cause the order is taking long … etc Most real life will not charge the customer is the chef can’t make the meal and cancel the cooking if the customer leaves The analogy maybe going far ;)
    • rawgabbit 3y ago
      True. If the customer leaves in mid process, we would have to issue a reversal transaction. Eat the financial loss, dispose of the food, and void the order the ticket.
      • anticensor 3y ago
        Or do it like a fast food restaurant: take the order, take the money, finalise the transaction but not commit (irreversible from that point on) then cook the food then commit: if the customer leaves before taking the meal, serve it to the next customer ordering the same meal.
• ncruces 3y ago
  You take either read OR write locks for whatever you need, and keep all locks until you commit the transaction. That (possibly brief) moment where you hold all the necessary locks is your point of linearizability: it's as if everything happened at that exact moment.