Relatively DB newbie here.
So I'm facing a recurring problem that multiple processes attempts Read-Modify-Write operations to the same DB instance, be it MongoDB, Redis, or SQL.
In Redis, one solution is to leverage the atomicity of the Redis Lua scripting to guarantee atomicity, but may result moving a considerable amount of application logic onto Redis. (whether good or bad?)
In SQL, it seems there are atomic stored procedures that achieves similar results, but also risking moving too much application logic into the DB itself (whether good or bad?)
MongoDB doesn't even really have a concept of internal scripting (the javascript solution seems to be deprecated)
Then in the general sense, as implied above, it might be good (?) to keep the application logic outside of the data store to achieve maximum application logic distribution and scalability across multiple nodes of services.
But making application logic distributed across multiple processes (nodes) and have them concurrently access the shared data store warrants the read-modify-write cycle to be guarded from possible race conditions.
So my questions are:
- for Redis or SQL, should I abuse the provided atomic scripting support to totally avoid any possible race, but putting more and more application logic into the data store, or
- is the read-modify-write model more common for the majority of the DB concurrency access, and if yes, are there some "standard" guidelines about how to synchronize the concurrent read-modify-write from multiple processes?
Thank!
