Is Mongodb's lack of transaction a deal breaker?

Question

I've been doing some research but have reached the point where I think MongoDB/Mongoose (on Node.js) is not the right tool for the job. Here is the scenario...

Two documents: Account (money) information and Inventory information

1. Check if user's account has enough money
2. If so, check and deduct inventory
3. Deduct funds from Account Information

It seems like I really need a transaction system to prevent other events from altering the data in between steps.

Am I correct, or can this still be handled in MongoDB/Mongoose? If not, is there a NoSQL db that I should check out, preferably with Node.JS support?

Answer 1

Implementing transactional safety is usually tricky and requires more than just transactions on the database, eg if you need to communicate with external parties in a reliable fashion or if the transaction runs over minutes, hours or even days. But that's leading to far.

Anyhow, on the db side you can do transactions in MongoDB using two-phase commits , but it's not exactly trivial.

There's a ton of NoSQL databases with transaction support, eg redis , cassandra (using the Paxos protocol ) and foundationdb .

However, this seems rather random to me because the idea of NoSQL databases is to use one that fits your particular problem. If you just need 'anything' with transactions, an SQL db might do the job, right?

Answer 2

You can always implement your own locking mechanism within your application to lock out other sections of the app while you are making your account and inventory checks and updates. That combined with findAndModify() http://docs.mongodb.org/manual/reference/command/findAndModify/#dbcmd.findAndModify may be enough for your transaction needs while also maintaining the flexibility of a NoSQL solution.

For the distributed lock I'd look at Warlock https://www.npmjs.org/package/node-redis-warlock I've not used it myself but it's node.js based and built on top of Redis, although implementing your own via Redis is not that hard to begin with.