Are Google Apps scripts reentrant?

Question

"Reentrant" may not be the right term, but I think it is close.

If I share a script with another user and we both execute it at the same time do we over-write each others variables?, or do the two executions happen in entirely distinct memory spaces?

Where can I read about this?

If reentrant is the wrong term, what is the correct one?

Update 14/10/03 o9:45 EDT: I don't think this warrants asking a new question.

I understand from Serge and Henrique that separate executions are "thread-safe" and that operations on shared resources need protection, presumably with Lock Service .

I am trying to decide how to rationalize my current ad hoc "strategy". I have a Web App that uses a spreadsheet for keeping track of a lot of settings, including querying another large spreadsheet for short-listed data. I shared copies with another user, then another. Now I have a mess of spreadsheets and script copies to keep track of. (It grew that way -- don't ask). I don't want to lose the "local cache" spreadsheets but I do want to avoid unnecessarily sharing multiple copies of a thread-safe script.

I'm considering a centralized lookup table that pairs a local cache spreadsheet with a given user, but it is really starting to look like I should rewrite the whole thing with BigQuery or some such, more serious storage. That looks like more effort than its worth though.

Any suggestion would be appreciated.

Update 14/10/03 12:15 EDT:

Originally the WebApp was contained in the spreadsheet, but I moved it out, so they are shared together. To add to the craziness. I now have a script that uses DriveApp to create directories, sharing with a user, copying in the spreadsheet and script and a few other things. In fact for security sake, in addition to the WebAppScript, I have WebAppScriptProxy that publishes the public functions of WebAppScript. That one is what the user interacts with.

Answer 1

Not only you and another user but also you and yourself between 2 different function calls from (for example but not only) 2 browser windows...

That's why you can't use global variable the usual way in Google Apps Script : each time you execute any function, all global variable are re-initialized and they are available only in the scope of this function call (and any function call made from within this function.

Keep in mind of course that this applies only to script variables and obviously not to documents or other permanent storage places (properties for example) where simultaneous execution will for sure create concurrency issues by overwriting each other.

Answer 2

It's in entirely distinct memory spaces.

I don't think " reentrant " is the most accurate term here, since there's no interruption of one's code to run another's. They all happen concurrently and safely. I'm not really sure what the correct term is. I guess you could say that the whole environment is "thread-safe", as they execute in different threads/processes and no variables are shared.

You only have to take care of shared resources, like a common spreadsheet or document property, etc.

--edit

It's difficult to understand your setup, but I'll suggest an approach anyway. First of all, I recommend that you have one only script and share only its deployed URL with your users (and not the script itself). About going Spreadsheet vs BigQuery, it's really impossible to advise against BigQuery. If you have the knowledge and are willing to work with it, then go for it. But I think you can work something out with Google Sheets, which due to its inherit concurrency nature is a pretty good simple database for scripts.

Bottom line, share with your users only what you must and keep everything else hidden. It's simpler for them and for you that way. For example, if they do not need to edit your "local cache" spreadsheet manually, then do share it with them. Again, if everything they need is the link to access your web-app, then don't make it more complex.

Answer 3

I tend to think of the scripts as closer to good old fashioned CGI scripts, written in Perl, Python, Bash, whatever. Only this time it is written in JavaScript.

Every time you hit the server, the web server launches a new version of the script from scratch.

It's a little fancier, in that it has a nifty framework it uses to shift information back and forth. But that's pretty much it.