Meteor: Could a race condition happen with Meteor.collections on server side?

Question

in my server/server.js

Meteor.methods({
    saveOnServer: function() {
        var totalCount = Collections.find({
            \"some\": \"condition\"
               


        

Answer 1

In Meteor's concurrency model, you can imagine a whole method as an uninterruptible block of stuff that happens. In order for Meteor to switch from running one method midway to say, starting another method, you need to "yield"—the method needs to signal, "I can be interrupted."

Methods yield whenever they do something asynchronous, which in practice means any time you do a database update or call a method with a callback in Meteor 0.6.5 and later. Since you give your update call a callback, Meteor will always try to do something in between the call to update and the update's callback. However, in Meteor 0.6.4.2 and earlier, database updates were uninterruptible regardless of the use of callbacks.

However, multiple calls to saveOnServer will happen in order and do not cause a race condition. You can call this.unblock() to allow multiple calls to saveOnServer to occur "simultaneously"—i.e., not share the same queue, labeled saveOnServer queue, of uninterruptible blocks of stuff.

Given the code you have, another method modifying Collections can change the value of count() between the call and the update.

You can prevent one method from making the other invalid midway by implementing the following data models:

saveOnServer : function () {
// ...
  Collections.update({_id:someId, initialized:true, collectionCount: {$gt: 0}},
    {$addToSet: {objects: object}});
///...
}

When adding objects to Collections:

insertObject: function() {
//...
  var count = Collections.find({some: condition}).count();
  Collections.insert({_id:someId, initialized:false, collectionCount: count});
  Collections.update({initialized:false},
    {$set:{initialized:true}, $inc: {collectionCount: 1}});
}

Note, while this may seem inefficient, it reflects the exact cost of making an update and insert in different methods behave the way you intend. In saveOnServer you cannot insert.

Conversely, if you removed the callback from Collections.update, it will occur synchronously and there will be no race conditioning Meteor 0.6.5 and later.

Answer 2

Another way to do this is from a mechanism hibernate/jpa follows - and that is to set up a collision field. Most of the time, this can be an update timestamp that is set on each update. Just prior to doing any update, query the update timestamp. Then you can specify the update where the update timestamp is what you just fetched. If it has changed in the interim, the update won't happen - and you check the return code/count that the row was updated or not. JPA does this automatically for you when you add an annotation for this collision field - but this is essentially what it does in behind the scenes

Answer 3

You can make this collection have a unique key on an index field, and then keep it updated as follows:

1) Whenever you insert into the collection, first do a query to get the maximum index and insert the document with index + 1.

2) To find out the number of documents just do the query to get the max of the index.

Insertion is now a pair of queries, a read and a write, so it can fail. (DB ops can always fail, though.) However, it can never leave the database in an inconsistent state - the Mongo index will guarantee that.

The syntax for building an index in Meteor is this:

MyCollection._ensureIndex('index', {unique: 1});