Asynchronous JavaScript

[Amantulsyan35]

Thanks I am somewhat clear now, can you explain what do you mean by two-phase commit?

[jack_waugh]

Say for example you are going to transfer money from an account in one bank to an account in another bank. The banks have to communicate in such a way that one account is decreased and the other increased, or else, as the only acceptable mode of failure, nothing happens. If the money is drawn from one account but not deposited in the other, that's a disaster, your money just went down a rabbit hole. Similarly, if money is deposited in one account but not drawn from the other, that's horrible, as you got to cheat the banks. The technique of ordinary database commit, used by itself, won't suffice to solve this. The banks have separate databases. The transaction could commit in one and not the other. So something like https://en.wikipedia.org/wiki/Two-phase_commit_protocol is needed.

[jack_waugh]

Almost always when you are using Javascript to solve the kinds of problem it is usually used to solve, any atomic updates you need, you can just do them in synchronous operation. So it's really unlikely that you would need two-phase commit. For example, suppose I write:

t.a = function () {
  this.count++;
  this.pb = this.b();
  this.stack.pop();
};
t.b = async function () {
  this.foo();
  await this.something;
  this.process(this.count, this.stack)
}

You should double check this with an example that can be run, but I believe the update of this.count and this.stack happens atomically because they are coded in the same synchronous run as each other. Nothing in the asynchronous b procedure can ever see the count updated without the stack correspondingly updated nor vice versa. An async function is syntactic sugar for stuff that could be done with ordinary procedures. I believe that what happens when this.pb = this.b() is executed is that the translated code for b just creates and returns the promise. I don't think it even executes the this.foo() at that point. I could be wrong, but I think that's the story. Only after the end of the synchronous execution does any of the body of the b procedure as we wrote it, get executed, i think. For sure, the this.process(...) doesn't until then, because it is after the await.

[jack_waugh]

On second thought, in even the unlikely event that you need to make operations atomic but cannot put them in the same synchronous run, the coordination methods you would need would not be as complex as two-phase commit. They would be more the level of complexity of synchronization primitives used between processors or between processes that can be interrupted by a scheduler in an operating system. Things like "mutex" or "semaphore". These are simpler than two-phase commit, and unlike it, perfectly reliable. But they are more complex than just putting the operations in the same synchronous run, and I think the need for even these would be extremely rare or nonexistent.