# When does atomic op \`SET\_VERSIONSTAMPED\_KEY \` return \`versionstamp\` with non-zero last 2 bytes?

**URL:** <https://forums.foundationdb.org/t/when-does-atomic-op-set-versionstamped-key-return-versionstamp-with-non-zero-last-2-bytes/3448>\
**Category:** Using FoundationDB\
**Created:** [July 13, 2022, 3:58am UTC](https://forums.foundationdb.org/t/when-does-atomic-op-set-versionstamped-key-return-versionstamp-with-non-zero-last-2-bytes/3448 "2022-07-13T03:58:43Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![gavinchou](https://avatars.discourse-cdn.com/v4/letter/g/ecc23a/32.png) [@gavinchou](https://forums.foundationdb.org/u/gavinchou)\
**Post date:** [July 13, 2022, 3:58am UTC](https://forums.foundationdb.org/t/when-does-atomic-op-set-versionstamped-key-return-versionstamp-with-non-zero-last-2-bytes/3448/1 "2022-07-13T03:58:43Z")

</div>

Hi, all

I followed the dev. manual [https://apple.github.io/foundationdb/api-c.html#c.FDBMutationType](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!

---

<div class="post-metadata">

**Author:** ![andrew.noyes](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/andrew.noyes/32/443_2.png) [@andrew.noyes](https://forums.foundationdb.org/u/andrew.noyes)\
**Post date:** [July 13, 2022, 4:00pm UTC](https://forums.foundationdb.org/t/when-does-atomic-op-set-versionstamped-key-return-versionstamp-with-non-zero-last-2-bytes/3448/2 "2022-07-13T16:00:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![gavinchou](https://avatars.discourse-cdn.com/v4/letter/g/ecc23a/32.png) [@gavinchou](https://forums.foundationdb.org/u/gavinchou)\
**Post date:** [July 14, 2022, 4:15am UTC](https://forums.foundationdb.org/t/when-does-atomic-op-set-versionstamped-key-return-versionstamp-with-non-zero-last-2-bytes/3448/3 "2022-07-14T04:15:07Z")

</div>

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!