4 ms·
Thanks for the detailed analysis. A quick thing to consider though, if redis.del fails, it can only mean redis is busted. This means, that none of the examples
by santosh_kumar 15y ago
Thanks for the detailed analysis. A quick thing to consider though, if redis.del fails, it can only mean redis is busted. This means, that none of the examples in any context that use redis in anyway have any bearing. Hence, guarding against that is a little excessive imo.
- eis 15y agoNo, it does not mean that redis is busted. It could be your client crashing (e.g. the OOM killer decided to pay a visit), the network between the client and redis failing (but not for other clients!) and so on. There are many reasons why the redis.del can fail and result in problems for the application.
- santosh_kumar 15y agoSo, this would mean every call you make to redis (not just the del) would need to be guarded against all of these reasons you have cited. To me that's just overkill. If transactionality is that important, redis may not be the right tool.
- eis 15y agoYes you need to make sure all your modifications lead to consistent states. If you don't do this, then you end up with inconsistent states and depending on your app deadlocks. Then it would only be useful as a cache and even then only if the temporary inconsistencies were tollerable. Using a datastore without guaranteeing (and be it only eventual) consistency is calling for trouble for any data that is worth something. Redis CAN be used for many things, but it's not always trivial to do it right even though at first glance it might look so and most web developers are lazy or just don't know better.