4 ms·
Can't seem to comment on the blog itself, so: > This code assumes the existence of a UUID library, which returns a unique ID on every call. Now, if more than o
by lamby 15y ago
Can't seem to comment on the blog itself, so:
> This code assumes the existence of a UUID library, which returns a unique ID on every call. Now, if more than one process were to run, they would each create their own temp_list’s
Wouldn't this still race in sense that a second update to the SafeIps table may be overwritten by the atomic move?
(A inserts into SafeIps and generates unique temp list, B inserts into SafeIps and generates another temp list, B moves its temp list to "safe_ips", A moves its temp list to "safe_ips" => oops, we've lost B's insert.)
- eis 15y agoCorrect. While the rename of safe_ips itself is atomic, it does not guarantee you that the value hasn't been updated in the meantime. That's what CAS is for.
- gokhan 15y agoExactly. The first example "fixes" the bug with checking first, but without any lock on the resource. If key's existence is a key problem in that design, who guarantees that "some_key" is still there after the long computation? He might equally be returning a nonexistent key's value. I think the problem is he's trying to use Redis as a transactional store while his design is not a good fit for it. He should either use a RDBMS for this stuff or change his design to match Redis' capabilities.
- santosh_kumar 15y agoWhat I've tried to show in the safe_ips example is just one thing. That the safe_ips list does not have to be deleted to be modified. The fact that redis semantics allows us to atomically do that is awesome. If process B were to overwrite the write process A had done or the other wa around, due to some timing issues, is irrelevant in the context of this example. If that is a concern, then a multi-exec or a setnx with a time-value is the way to go.
- Detrus 15y agoYou have to use Redis' INCR to generate the UUIDs.
- eis 15y agoThat does not help at all with the issue at hand. The problem is not colliding UUIDs, it is a race condition between getting the list of IPs and then writing them to redis.
- Detrus 15y agoOh, well in the pseudo(?) code he seems to push the content from temp lists into the main list, so it seemed that as long as you have separate temp lists for A,B you wouldn't lose anything, but I probably misread it. But anyway, as the other comment mentions, there is some transaction support http://redis.io/topics/transactions http://redis.io/topics/transactions I'm not sure how much Redis will focus on transactions but if it doesn't you're out of luck or reinvent the SQL wheel on top of it.
- ymir 15y agoIs it neccessery to use UUIDS? Why not use Redis sets instead of list so we'll get rid of key duplication problem?