Mutual exclusion to avoid multiple (asynchronous) script execution

[ludovic....@gmail.com]

Google Apps Script is great because it inherits some asynchronous features of JavaScript, but can be disastrous if misused..

How can I protect scripts in order to avoid any concurrent execution?

I have noticed that Lock service has id and other stuffs which I believe are stored in Google's servers (so available from any users at any time). I don't think that it is possible to store state between calls.

I don't understand how TryLock() and WaitLock() work. Can anyone explain it a bit? I find the documentation not so clear. Why it is time-based? Do I have to estimate how long it takes for the script to execute?

Also, why is there no basic SetLock()? (Like HasLock() and ReleaseLock()).

Thanks for any insights!

[Alan Wells]

Please see the discussion from this group at:

https://groups.google.com/g/google-apps-script-community/c/Vy_gw6Z_0SY/m/WOjRXVzaAAAJ

[Adam Morris]

Hi there Ludovic,

AppsScripts is certainly an interesting platform, for the reasons you mentioned. I just want to provide a bit more context, and then cover the lock service.

The server side code that is executed on google’s servers, which is often the backend of a web app, for example, is syncronous. While you can use some of the syntax and keywords of async code, such as promises and async/await, it ain’t actually async.

https://gist.github.com/brainysmurf/afb107c7d0e3d8c1785b1320bdd469b4

Where the stack is async, is in the browser. So if you have a web app with some javascript code written in an html file in the project, that is actually executed in the browser runtime.

So you could perhaps have a web app that connects with server-side appscript code that writes to the spreadsheet. The browser could be potentially doing so as the same user, by the user clicking over and over again, but writing to the spreadsheet might cause complications, such as a race condition. You therefore are logically required to make it so that a piece of code is locked, so that that same piece of code cannot be executing at the same time. 

These would be separate instances of the runtime being executed at the same time, not the code itself having asyncronous features. (Important distiction to keep in mind as we reason about how the stack works.)

This is where timing comes in, because the programmer indicates to the runtime the start of the protected block of code by calling a function that will block, and only return when it’s “my turn” to start executing the protected piece of code. How long are you willing to wait until it’s your turn? It depends on the context, which the programmer has to decide.

I hope you found this educational :)

Adam

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/6dadd195-2bcf-4bc4-ad38-007257cec1b0n%40googlegroups.com.

--

http://classroomtechtools.com