Reputation: 2101
I am trying to figure out how to avoid a race condition when I update redis. This is my scenario: I have a message that has been broken up into several http GET requests, due to query param length constraints. I am using redis to store the temporary message chunks, and when I have all the chunks, I concatenate them and store them in the DB. The chunks are tagged with a message id, and I store the chunks in a '$' delimited string, keyed by the message id. I get the chunks string when I get a new chunk, and then append the new chunk + '$', and set it back in redis. The problem is that I am worried that if I call set, and that set command has not finished executing before my next get, I won't have the latest chunk string. If I have a single redis client, perhaps that will mitigate this issue, since presumably the commands are executed in order received on the server? Any insight appreciated, including suggestions on how to architect message re-assembly in more sane way? Thank you.
Upvotes: 1
Views: 603
Reputation: 49932
The simplest thing to do here would be to use Redis' APPEND command - this will save you the round trip of GETting the value and will ensure the atomicity of the operation.
Upvotes: 3