Is the mset command atomicity?

[rawvoid]

Hi, guys

I'm just getting started with kvsocks and it has a lot to offer me. But I don't know enough about it. I know it is based on rocksdb, and rocksdb supports transactions, so does the mset command have the atomicity of transactions? When the system fails, will the previous insertion be automatically rolled back? Thanks.

Regards

[git-hulk]

It's NOT an atomic operation in MSET command, but we can improve it since we supports multi-key locks now.

For more detail can see: https://github.com/apache/incubator-kvrocks/blob/unstable/src/types/redis_string.cc#L356

[rawvoid]

Hi, @git-hulk

Maybe some want it to be like redis! Will the development team agree to this improvement? Can the multi and exec command combination of kvrocks automatically roll back after an unexpected error?

Regards

[git-hulk]

Sure, It should be easy to improve the mset command, but the multi/exec should have a lot of work to achieve this.

[rawvoid]

That's really nice. I'm looking forward to it. I don't know how to develop in C++, otherwise I would submit a PR.

[rawvoid]

Hi, @git-hulk

Thank you for your clarification.

Things looked different than I expected. Now I have a batch of key values that need to be inserted, but I want them to be executed in the same transaction (rollback if it fails). For this I am looking for a solution. Redis has transactions, but it doesn't seem to be complete as it can't handle rollbacks. Can you tell me how kvrocks achieves this? Thanks.

Regards

[git-hulk]

RocksDB supports write batch, we can commit those mset key values at once instead of one by one.

[ediphy-dwild]

related clarification question:

in the absence of any failure:

• if a writer performs a single HMSET command
• can any reader observe the existence of the hash before it is fully constructed?

one example of this potential race:

• a writer creates a hash of 200K key values with a single HMSET
• can any reader see that the hash exists, but fail to HGET one of the keys that the writer added/is-still-in-the-process-of-adding to the new hash?
• or can a reader HGET one of the keys but fail to HGET another key - but then try again 'later' and succeed for both keys?

many thanks in advance

[git-hulk]

are you saying that a reader can see a partially constructed hash (really bad, for our use case) or that readers cannot see a partially constructed hash (our expected behaviour).

No indeed, readers cannot see anything before the writer committed.

[ediphy-dwild]

great. that means that in the absence of failure, writes to hashes are all-or-nothing (ie atomic), which is what we need to match the existing redis behaviour.

where writes to hashes are non-atomic, is in the case of a system failure, i assume?
"It's NOT an atomic operation in MSET command, but we can improve it since we supports multi-key locks now."

[git-hulk]

The MSET command will write key values one by one before PR #1634, so it may cause a partial commit if the server crashed in the middle. But HMSET didn't have this issue since it always writes all fields at once.

[ediphy-dwild]

perfect - that explains things. thankyou very much for your time!

[git-hulk]

You're welcome