For some workloads where there is time between finding a record and updating it, it would be helpful to reserve records for use by the current transaction. If the "reserve" operation succeeds for a record, the transaction should be able to update the record in future without the chance of a write conflict. In other words, any concurrent transaction running at snapshot isolation that attempts to update a reserved record will fail.

The suggested implementation is a new type of WT_UPDATE that is a "pass-through". It doesn't contain any data but has the reserving transaction's ID, and readers that would normally find the update visible should instead continue to the next visible update.

To keep the maintenance of obsolete versions from taking these special updates into account, I suggest that they are always rolled back (i.e., the transaction ID set to WT_TXN_ABORTED, even on commit. This may require logging reserve operations with a new WT_TXN_OP_RESERVE operation type, and setting a flag in the transaction if it performs a reserve, because commit otherwise does not walk txn->mod.

Reconciliation should never find such an update because reconciliation should never write an uncommitted update, and should assert that.