When does atomic op `SET_VERSIONSTAMPED_KEY ` return `versionstamp` with non-zero last 2 bytes?

Using FoundationDB
1

Hi, all

I followed the dev. manual https://apple.github.io/foundationdb/api-c.html#c.FDBMutationType,
and tried to get as many concurent transactions as I can to produce non-zero ending bytes of versiontimestamp, I always got versiontimestamp s ended with 0x0000.

I am wondering under what kinds of scenarios SET_VERSIONSTAMPED_KEY and SET_VERSIONSTAMPED_VALUE will result in a versiontimestamp that does not end with 0x0000?

Is it safe for my app. to ignore the trailing 2 bytes and use an int64 for the first 8 bytes to represent a globally monotonic unique id? If not, what’s the chance that I will get 2 int64 with the same value?

I’ve searched the forum and read lots of docs, but nothing was found to help resolve my question, so I start a new topic to ask for help.

Thank you!

2

Welcome! Do you have example code you can share? I do expect that many small concurrent transactions setting version stamps would end up with non-zero trailing two bytes in those version stamps.

3

Hi, @Andrew, thank you for your kind reply.

Your reply reminds me that the concurrent transactions should be small enough.
And, I rewrite my test in a multi-process pattern with many small transactions (only one atomic_op per transaction), I get lots of version stamps that end with 0x0001 or 0x0002.

Thank you!