Description
Some use cases that might otherwise require nested transactions can be served simply by being able to acquire multiple write pointers in a single transactions. For example, when scanning over a table and issuing puts against the same table, we want to be able to see prior writes to the table in the current transaction ("read your own writes" semantics), but not writes that are part of the current scan/put operations. To coordinate this, we can perform a "checkpoint" on the current transaction, which will flush any pending commits, and make a request to the transaction service for a new write pointer. When we perform the scan/put operations, any writes with the prior write pointer(s) will be visible, but the current write pointer will be excluded. This will eliminate the possibility of entering into an infinite loop during the scan/put cycle.
Attachments
Issue Links
- is related to
-
TEPHRA-201 In-progress transactions may become visible when transactions are checkpointed
- Resolved
-
TEPHRA-39 Support Nested Transactions
- Open
-
TEPHRA-141 Reconcile TransactionId v/s Write Pointer usages
- Open