When working with requests that share resources via web frameworks that deal with threads, the large consensus is to put the resource into an external managed resource. This external resource such as a database will manage the locking for you to prevent write conflicts, however, when caching values for complex interaction beyond CRUD you may have update conflicts where a new request has an in memory copy of an outdated resource. This is where the problem lies.
well, that's a cache invalidation issue. Any data that's cached, by definition may not be the freshest version, unless you've implemented a very nice write-through situation. If you'd like multiple requests to share an in-memory-only cache, potentially using write-through, then yes that deals with synchronization issues. I wouldn't characterize them as super-tough synchronization issues and you certainly won't have a "blocking IO" problem with an in-memory system.
If you want to write your own caching server, fine, use node.js. But now you're writing your own cache server, you've found some problem that memcached, redis, etc. all do not solve. Is this an everyday use case ?
For me it is. However i tend to just use in-memory caches instead of a cache server, which may suffer the same issue. For standard websites, this is a non-issue for CRUD, for task/activity based sites that can have long lived tasks that persist after a request this is very important.
By giving a shared in-memory resource for the current state of an object that is not mutated from other threads during a single stack build / teardown. Concurrent access in threads requires locking the object until it is in a determinate state, while in Node you are guaranteed the state until the stack unwinds.
But this isn't unique to Node, is it? It seems like you're saying you've added a feature when you've really removed one. You can create a single threaded event loop in any language and get the same properties, no?
I'd argue something like Clojure is actually providing a feature here, instead of taking something away from your toolkit. You can have a single view of an object for the life of, say, a request all while its root binding is actually being mutated by other threads. You won't "see" the new value until you deref the root binding on the next request. Except nobody stole threads from you and sent you a bill.
Perhaps it is taking away a "feature" in some senses, but in my view it is taking the logical step not allowing concurrent access to preempt during execution. I often want the current value that has changed after the original context is changed by an asynchronous task (IP addresses of internal servers changing while a script was running came up today).
There is no way preempting access / memory contention is a feature, but Clojure avoids this with somewhat immutable state which can make keeping up to date values painful, although I may not be experienced enough to state much about Clojure.
For web services such as ours where we have values changing underneath us it is elegant that we keep a value the same through a single flow of control (until the stack unwinds). Even if it is incorrect for one part of the task as a whole, it is predictable where the values can change and dealing with errors from pointing to the wrong object / value is trivial compared to most race conditions (yes, node does those before anyone jumps in).
The environment here is key though. Node was built as a single threaded event loop. All the bindings for node / libraries for node expect this. Libgmp's love of aborting threads after a process gives it a wrong value is a good example of where the single threaded environment fights the threaded model, and the same problems of expecting threads is apparent in many programming environments (.Net Http stack I'm looking at you).
So in many ways: Node does not give you something that cannot be done in other environments; but, in other environments there is a lot of existing code that encourages thread usage. Doing something in twisted or the like proved difficult once I needed libraries that had been written expecting threads. The same is true in Node, but I can be confident that good libraries / bindings for Node provide things that expect to work in a single threaded event loop. And I like the command queue / event loop / actor based / reactive / whatever you want to call it. I like it more than anything due to the lack of concurrent edits, but allowing a lot of mutability at the same time.
Only one is used for computation (afaik), the rest are used to toss I/O onto. gevent/eventlet in Python do the same, as do other languages. Nothing unique there.
