If multiple users are trying to access one method of Meteor.methods , how to make method as synchronous to use one user only at a time?


#1

If multiple users are trying to access one method, how to make use of it at a time one user only?

eg:

Meteor.methods({

getSession: function() {
var session = Session.findOne({_id:‘abc’});
if(session !== undefined){
var sessionId = session._id;
return sessionId;
}
}

});

How to use lock concept in this scenario?


#2

Using semaphores to manage co-operative processes is not easy, especially in a multi-server environment, where the testing and setting must be done atomically. When you factor in the need to clear a semaphore if the locking process has failed, it can become messy if you don’t know what you are doing.

For doing this in a simple, multi-server safe way with automatic (albeit naive) clearing of long running locks, you could look at using a MongoDB collection. For atomic test and lock, use findAndModify (in Meteor this needs to be done on the rawCollection). To clear long running locks, set a TTL on a timestamp field which is marginally longer than the worst case expected lock time (this can only be set in multiples of 1 second).

However, you may not need to do this - what are you actually wanting to do?


#3

Hi @robfallows ,

Thank you for your time.

Actually I would like to avoid a race condition while clicking a button by two users at a time which event(client) will call the above method(server). If any users clicks shouldn’t allow another user up to completion of one user’s request.


#4

Your example (BTW using Session for a collection may be confusing, especially if you include Session on your client) does nothing which needs protection from a race.


#5

Session means it’s a collection over MongoDB.
When a user clicks a button, call will come to the above method. Which will retrieve some value from DB(Session means a collection name in DB) and return back to the client. So, as per our requirement no two users can clicks a button at a time. Even though they clicks, race condition shouldn’t come like same return value shouldn’t go for both clicked users. In java we have thread and lock concept to avoid the above condition. Is there any lock mechanism to lock a piece of code or method up to completion of the call.


#6

Yes, I know that - I’m just saying it may be confusing.

Not natively. You could code your own following the suggestions in my first reply, or you could search NPM for “semaphore”. There are a few (I’ve not evaluated any of them).

However, I’m still not seeing the need for this in your code - you are not mutating your collection, so it makes no difference how many “simultaneous” clients call the method - they’ll all get the same result.


#7

In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. We find the linear execution model a better fit for the typical server code in a Meteor application.
http://docs.meteor.com/#structuringyourapp

Can i go a head with this info.?


#8

In a single-server environment (as you would have when developing a Meteor app), you get one nodejs thread. In order to allow multiple processes to use that thread without (apparently) blocking other processes, node uses something called the event loop (there’s a good explanation here: http://softwareengineeringdaily.com/2015/08/02/how-does-node-js-work-asynchronously-without-multithreading/).

In order to simplify code writing, Meteor’s server uses coroutines (with the Fibers package) to give the appearance of synchronous code. This avoids the “callback hell” which has traditionally been the result of coding for node. It does not preclude multiple clients from running the same method “simultaneously” on the server. However, it does mean that any one client’s method calls will run in sequence (unless you explicitly change that behaviour).

The situation becomes more difficult to reason about in a scale-out, production environment, where there is no co-operation between server instances (each gets an independent thread, doing its own thing).

If you really believe that you need resource locking between clients I think you’ll have to do it yourself.