Concepts
Tentative operations and reservations
Intuition
Think of booking a table at a restaurant: the restaurant sets the table aside for you without knowing whether you will show up, and you keep the right to back out. In the meantime, both sides live with a shared uncertainty, until the reservation is confirmed or canceled. Nobody needs to lock up the whole restaurant, nor do both sides have to decide everything at the same instant, for the arrangement to work.
How it works
Helland's paper starts from an abstraction called an entity: a collection of data with a unique key, within a single scope of serializability (one machine or a small cluster). Within an entity it is possible to run atomic transactions; across entities it is not, because the layer underneath may place them on different machines and move them when repartitioning. The link between entities is therefore a message, delivered at least once, which forces the application to process everything idempotently. Without atomicity across entities, reaching an agreement means accepting uncertainty for a while, and this is where the tentative operation comes in: one entity asks the other, by message, to take on a commitment that leaves open the possibility of cancellation. Whoever accepts agrees to let the requester decide the outcome; if the requester releases the right to cancel, a confirm occurs, and if it gives up, a cancel occurs, so every tentative operation eventually confirms or cancels. Each entity records this state per partner in an activity, for example one activity per order inside each item of a warehouse. In distributed transactions this uncertainty shows up as locks in the transaction manager; here it moves into the business semantics, and the author sums it up as fine-grained workflow with entities as participants.
In practice
In the paper's example, the warehouse allocates stock for an order without knowing whether it will be used, and only later finds out whether it is needed; the author indicates that the uncertainty becomes business concepts such as reserved stock or allocation against a line of credit. Choosing this design makes sense when scale forces you to give up distributed transactions: each entity keeps its local transactions, and coordination between them becomes reservation, confirmation or cancellation. The cost is that the application must model the intermediate state and tolerate repeated messages.
Use it in a design
Practice the cases that rely on this concept in the System Design school.