4 ms·
I see your point, and if all you need is a HashMap then use a HashMap. But if that data in the HashMap must be available to another process, or you need more "
by gizzlon 15y ago
I see your point, and if all you need is a HashMap then use a HashMap.
But if that data in the HashMap must be available to another process, or you need more "features", Redis suddenly looks like a very easy solution.
- jshen 15y agoThe point is that you don't need multiple processes and Redis most of the time. Your site can easily be served from one box and one process.
- deleted 15y ago[deleted]
- jasim 15y agoEven multiple threads - any sort of concurrent access/modification on the same dataset becomes problematic if you just use a HashMap. Sites that have any kind of download/upload component, even though does not have too much traffic, will need to serve multiple requests using threads/processes. That is where we normally use relational database. However Redis presents a way to be faster than conventional databases by storing everything in memory. This is as close to a concurrency-safe HashMap that you can get with the least amount of effort.
- willvarfar 15y agoBut Java comes with several currency-safe hash-maps and trees and such - where have you been? If you think that blocking TCP calls to a redis server that serialises everything is going to be faster than a `new HashSplayTree<String>()` you're absolutely bonkers.
- jshen 15y ago"This is as close to a concurrency-safe HashMap that you can get with the least amount of effort." No, it's more effort than using a concurrency-safe HashMap in a JVM process.
- gizzlon 15y agoThat depends on what you're creating and how. For better or worse[1], not everything follows the one-enormous-process Java way of doing things. Btw, Redis is extremely fast to set up, but as I sai, if all you need is a HashMap.. [1] - Almost always for the better if you ask me. That Java "enterprisy" way of development is the worst thing I have ever experienced in computing ;)