Two different clients can call the same method, myMethod.
Suppose they call the method at roughly the same time, but client B’s gets handled first. I don’t want client A’s call to get handled until client B’s handler has exited.
I know that on a PER CLIENT basis, method calls are executed synchronously, by default (unless we manually this.unblock). I am wondering if this is true across all clients at the same time.
As a bonus, how can this behavior be extended for clustered environments?
is that possible to setup type for the clients, so the same method can handle those types properly?
I think you’re asking for transactions or locks. You can accomplish that easily in a single-server setup with a variable, but in a multiple server setup it’s very very difficult. What’s the specific case? Perhaps there’s a way to implement it where it’s OK for two methods to run at once?
A user can initiate a service request, and the first person to accept the
request is assigned the task. Braintree/charges are involved. I can’t have
two servicemen get assigned the same request, because that would initiate
two monetary transactions. Also, I can’t have one serviceman assigned too
many requests (but they can have multiple), which could happen if two large
requests are made at once and both think that the serviceman has enough
"open slots" left.
I’m thinking of doing two way two-phase updates… Only let a serviceman
get assigned a request one at a time, and only let a request get picked up
one at a time. This prevents a serviceman from getting overencumbered and
it prevents a request from getting accepted by more than two people at once.
This seems rather straightforward. Am I failing to understand some challenge?
So you basically have a queue of tasks and a pool of workers right? When a worker requests a task, can’t you check to see if it’s already assigned (task.assignedWorkerId is null), and if not assigned it (set task.assignedWorkerId=P6Hd672m). That’s your lock. A task can only have one worker, so just used an assignedWorker field.
If you want to ensure the payment was processed successfully, then include a separate status field in your logic. I.e. task is provisionally assigned to a worker, but not released until Task.paymentStatus = Complete.
Perhaps you’ll need a routine to reset any tasks after a certain timeout i.e. if payment for an assigned task wasn’t completed within 60 seconds, then the assignedWorkerId for that task is set back to null (releasing the task for another worker.
You may want to take a look at this package, we use state machine extensively in our app to manage this sort of thing
Hi Max, thanks so much for your reply. Yes this is what I meant with the
two phase commit, a similar example is detailed fully in the mongo
documentation!
Glad to know your thought process, this will be the first time I implement
it, so your feedback helps a lot.
I’ll take a look at your state machine. It looks like a lib might be useful
so I don’t have to rewrite the wheel.
I’m super excited, I’ll be able to scale my app pretty easily with an
n-worker; task-queue paradigm…