If I understand versionstamps correctly, they are 12 bytes (Java): the first 8 being the transaction version, next two being batch order if FDB determined multiple transactions could be committed under the same version, and the final two bytes being an optional client-assigned order.
Since many systems use 8-byte
long values as ids, I’d like to be able to piggyback off of versionstamps to generate an increasing long-sequence without extra coordination/reads, but truncating 10–>8 bytes won’t be safe if the commit was batched together with another.
Maybe I’m wholly barking up the wrong tree, but one option I was wondering about is applying the hidden
first_in_batch transaction option to all commits being used to generate 8-byte ids, since I’m imagining two
first_in_batch transactions cannot be coalesced. This way, all normal transactions proceed just fine, and id-generating ones are forced to get a 00 batch order. Or maybe I have no idea how this option works
Any other approaches to consider? Something like the high-contention allocator wouldn’t match my exact use case, since the sequence needs to be increasing.