(This is mostly just out of curiousity)
Suppose I want read-write transactions lasting longer than 5 seconds. This could in theory be done in a layer by maintaining an index from version to write conflict range in a special subspace. A transaction would get an initial read version r0, perform reads at this version, and then have a long think about things (maybe it’s a user deciding what to do). To commit the transaction you could get a second read version r1, accumulate the write conflict range from r0 to r1 by reading the index at r1, manually check if the accumulated write conflict range intersects your read conflict range, and if not submit the transaction with read version r1 and the union of all reads performed at r0 and r1 as your read conflict range. If the index at r0 has been purged by some background cleaner job you have to abort the transaction. Basically you check for read-write conflicts from r0 to r1 manually in a layer, and then the resolver checks for read-write conflicts after r1.
A couple questions:
- Does this seem sound? I think it still achieves serializability but maybe I’m missing something.
- It would be useful to read your transaction’s read conflict range and write conflict range before committing. It would be possible to keep track of this manually but the native api is already keeping track of it so it’d be nice to just reuse that. Maybe there could be \xff\xff keys for this.