CODEWITHSUNDEEP
node.jsmongodbmongoose
alexislg
alexislg

Reputation: 1016

How to read/write a document in parallel execution with mongoDB/mongoose

I'm using MongoDB with NodeJS. Therefore I use mongoose.

I'm developing a multi player real time game. So I receive many requests from many players sometimes at the very same time.

I can simplify it by saying that I have a house collection, that looks like this:

{
    "_id" : 1,
    "items": [item1, item2, item3]
}

I have a static function, called after each request is received:

house.statics.addItem = function(id, item, callback){
    var HouseModel = this;
    HouseModel.findById(id, function(err, house){
        if (err) throw err;
        //make some calculations such as:
        if (house.items.length < 4){
            HouseModel.findByIdAndUpdate(id, {$push: {items: item}}, cb);
        }
    });
}

In this example, I coded so that the house document can never have more than 4 items. But what happens is that when I receive several request at the very same time, this function is executed twice by both requests and since it is asynchronous, they both push a new item to the items field and then my house has 5 items.

I am doing something wrong? How can I avoid that behavior in the future?

Upvotes: 1

Views: 3357

Answers (4)

David
David

Reputation: 972

I am also building a multiplayer game and ran into the same issue. I believe I have solved it my implementing a queue-like structure:

class NpcSaveQueue {
    constructor() {
        this.queue = new Map();
        this.runQueue();
    }

    addToQueue(unitId, obj) {
        if (!this.queue.has(unitId)) {
            this.queue.set(String(unitId), obj);
        } else {
            this.queue.set(String(unitId), {
                ...this.queue.get(unitId),
                ...obj,
            })
        }
    }

    emptyUnitQueue(unitId) {
        this.queue.delete(unitId);
    }

    async executeUnitQueue(unitId) {
        await NPC.findByIdAndUpdate(unitId, this.queue.get(unitId));
        this.emptyUnitQueue(unitId);
    }

    runQueue() {
        setInterval(() => {
            this.queue.forEach((value, key) => {
                this.executeUnitQueue(key);
            })
        }, 1000)
    }
}

Then when I want to update an NPC, instead of interacting with Mongoose directly, I run:

npcSaveQueue.addToQueue(unit._id, {
                "location.x": newLocation.x,
                "location.y": newLocation.y,
            });

That way, every second, the SaveQueue just executes all code for every NPC that requires updating.

Upvotes: 1

binki
binki

Reputation: 8308

One possible approach since the release of Mongoose 4.10.8 is writing a plugin which makes save() fail if the document has been modified since you loaded it. A partial example is referenced in #4004:

@vkarpov15 said:

8b4870c should give you the general direction of how one would write a plugin for this

Since Mongoose 4.10.8, plugins now have access to this.$where. For documents which have been loaded from the database (i.e., are not this.isNew), the plugin can add conditions which will be evaluated by MongoDB during the update which can prevent the update from actually happening. Also, if a schema’s saveErrorIfNotFound option is enabled, the save() will return an error instead of succeeding if the document failed to save.

By writing such a plugin and changing some property (such as a version number) on every update to the document, you can implement “optimistic concurrency” (as #4004 is titled). I.e., you can write code that roughly does findOne(), do some modification logic, save(), if (ex) retry(). If all you care about is a document remaining self-consistent and ensuring that Mongoose’s validators run and your document is not highly contentious, this lets you write code that is simple (no need to use something which bypasses Mongoose’s validators like .update()) without sacrificing safety (i.e., you can reject save()s if the document was modified in the meantime and avoid overwriting committed changes).

Sorry, I do not have a code example yet nor do I know if there is a package on npm which implements this pattern as a plugin yet.

Upvotes: 1

Andras
Andras

Reputation: 3055

yes, you need better locking on the houseModel, to indicate that an addItem is in progress.

The problem is that multiple requests can call findById and see the same house.items.length, then each determine based on that (outdated) snapshot that it is ok to add one more item. The nodejs boundary of atomicity is the callback; between an async call and its callback, other requests can run.

One easy fix is to track not just the number of items in the house but the number of intended addItems as well. On entry into addItem, bump the "want to add more" count, and test that.

Upvotes: 2

cehmja
cehmja

Reputation: 140

This function never executes twice, because update operation is atomic on a level of single document. More info in official manual: http://docs.mongodb.org/manual/core/write-operations-atomicity/#atomicity-and-transactions

Upvotes: -2

Related Questions