Am I using the Google Apps Script Lock Service correctly?2019 Community Moderator ElectionGoogle Apps Scripting Web App Auto Refreshing LabelsUsing Google Sheets API from within Apps Script for same SheetHow to expose a web API to a google apps scriptHow to understand LockService and implement it correctly?Google App Script and public locksAccessing Google Sheets with an Apps Script web appWrite to file in app script projectThere are too many LockService operations against the same scriptScript can't access the Google-Apps-Script web-appGoogle apps script no access via sheet
Why does Surtur say that Thor is Asgard's doom?
Writing in a Christian voice
Why doesn't the fusion process of the sun speed up?
Triple Trouble Tribond
Weird lines in Microsoft Word
Does fire aspect on a sword, destroy mob drops?
CLI: Get information Ubuntu releases
Splitting fasta file into smaller files based on header pattern
Don't understand why (5 | -2) > 0 is False where (5 or -2) > 0 is True
Print a physical multiplication table
Emojional cryptic crossword
Is VPN a layer 3 concept?
is this saw blade faulty?
Do people actually use the word "kaputt" in conversation?
What is the tangent at a sharp point on a curve?
How to remove space in section title at KOMA-Script
When did hardware antialiasing start being available?
Determine voltage drop over 10G resistors with cheap multimeter
Friend wants my recommendation but I don't want to
Norwegian Refugee travel document
Why is participating in the European Parliamentary elections used as a threat?
Single word to change groups
label a part of commutative diagram
PTIJ: Which Dr. Seuss books should one obtain?
Am I using the Google Apps Script Lock Service correctly?
2019 Community Moderator ElectionGoogle Apps Scripting Web App Auto Refreshing LabelsUsing Google Sheets API from within Apps Script for same SheetHow to expose a web API to a google apps scriptHow to understand LockService and implement it correctly?Google App Script and public locksAccessing Google Sheets with an Apps Script web appWrite to file in app script projectThere are too many LockService operations against the same scriptScript can't access the Google-Apps-Script web-appGoogle apps script no access via sheet
I have 3 Apps Script functions in a script. The script is deployed as a public access Web App.
Each function reads from a it's own google sheet. Each function does not write anything to the sheets.
I have applied the Apps Script 'LockService' to each function to prevent multiple users accessing the spreadsheets, via the webapp, at the same time. In effect making each user wait until the previous user's script has finished reading. They they get to read the 3 sheets.
I've found this can sometimes create a bit of a delay of 4 or 5 seconds for users before the App is updated - which is quite off putting.
My question then is should I -
a) bother with the LockService, as I am just reading the spreadsheet data and perhaps the main purpose of LockService is to prevent conflicts between concurrent read AND writes
Or
b) am I correct to implement it, as reading data concurrently could also cause conflicts is getting things like Range values etc.
thanks
EDIT: if option 'a' then I wonder what the purpose of LockService is? Is one reason perhaps (as I have elsewhere in other scripts) when you use multiple 'google.script.run.' One after the other to access the same spreadsheet, via different functions, then - as these run asynchronously - there could be conflicts created if both requests are trying to Get data.
just musing really....
google-apps-script web-applications
add a comment |
I have 3 Apps Script functions in a script. The script is deployed as a public access Web App.
Each function reads from a it's own google sheet. Each function does not write anything to the sheets.
I have applied the Apps Script 'LockService' to each function to prevent multiple users accessing the spreadsheets, via the webapp, at the same time. In effect making each user wait until the previous user's script has finished reading. They they get to read the 3 sheets.
I've found this can sometimes create a bit of a delay of 4 or 5 seconds for users before the App is updated - which is quite off putting.
My question then is should I -
a) bother with the LockService, as I am just reading the spreadsheet data and perhaps the main purpose of LockService is to prevent conflicts between concurrent read AND writes
Or
b) am I correct to implement it, as reading data concurrently could also cause conflicts is getting things like Range values etc.
thanks
EDIT: if option 'a' then I wonder what the purpose of LockService is? Is one reason perhaps (as I have elsewhere in other scripts) when you use multiple 'google.script.run.' One after the other to access the same spreadsheet, via different functions, then - as these run asynchronously - there could be conflicts created if both requests are trying to Get data.
just musing really....
google-apps-script web-applications
add a comment |
I have 3 Apps Script functions in a script. The script is deployed as a public access Web App.
Each function reads from a it's own google sheet. Each function does not write anything to the sheets.
I have applied the Apps Script 'LockService' to each function to prevent multiple users accessing the spreadsheets, via the webapp, at the same time. In effect making each user wait until the previous user's script has finished reading. They they get to read the 3 sheets.
I've found this can sometimes create a bit of a delay of 4 or 5 seconds for users before the App is updated - which is quite off putting.
My question then is should I -
a) bother with the LockService, as I am just reading the spreadsheet data and perhaps the main purpose of LockService is to prevent conflicts between concurrent read AND writes
Or
b) am I correct to implement it, as reading data concurrently could also cause conflicts is getting things like Range values etc.
thanks
EDIT: if option 'a' then I wonder what the purpose of LockService is? Is one reason perhaps (as I have elsewhere in other scripts) when you use multiple 'google.script.run.' One after the other to access the same spreadsheet, via different functions, then - as these run asynchronously - there could be conflicts created if both requests are trying to Get data.
just musing really....
google-apps-script web-applications
I have 3 Apps Script functions in a script. The script is deployed as a public access Web App.
Each function reads from a it's own google sheet. Each function does not write anything to the sheets.
I have applied the Apps Script 'LockService' to each function to prevent multiple users accessing the spreadsheets, via the webapp, at the same time. In effect making each user wait until the previous user's script has finished reading. They they get to read the 3 sheets.
I've found this can sometimes create a bit of a delay of 4 or 5 seconds for users before the App is updated - which is quite off putting.
My question then is should I -
a) bother with the LockService, as I am just reading the spreadsheet data and perhaps the main purpose of LockService is to prevent conflicts between concurrent read AND writes
Or
b) am I correct to implement it, as reading data concurrently could also cause conflicts is getting things like Range values etc.
thanks
EDIT: if option 'a' then I wonder what the purpose of LockService is? Is one reason perhaps (as I have elsewhere in other scripts) when you use multiple 'google.script.run.' One after the other to access the same spreadsheet, via different functions, then - as these run asynchronously - there could be conflicts created if both requests are trying to Get data.
just musing really....
google-apps-script web-applications
google-apps-script web-applications
edited Mar 8 at 9:14
MrPea
asked Mar 7 at 18:36
MrPeaMrPea
104110
104110
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You do not need to use the LockService if all you're doing is reading data. Therefore, option (a).
There's no need to protect Apps Script or Google Sheets from concurrency, even write operations from the same user. Each parallel access you do from Apps Script runs completely independently from each other, it is a new instance of your app that do not share anything with others, it might even be running on a different server entirely. And Google Sheets handle concurrency just fine, concurrent collaboration is the whole point of the G Suite apps.
So, when do you need LockService?
When your app logic requires such. For example, to protect itself from messing up its own data. Let's say you want to count how many clicks you had and save that number on a sheet, e.g. Sheet1!B2. So your code would look like:
function countClicks()
var r = SpreadsheetApp.getActive().getSheetByName('Sheet1').getRange('B2');
var clicks = r.getValue();
clicks = clicks + 1;
r.setValue(clicks);
If this function runs concurrently, you're not going to corrupt your memory or make Google Sheets break, all that's going to happen is that you might overwrite yourself, as if you had multiple users trying to type in the same cell: the last one wins.
But your logic would be broken, that is, multiple concurrent clicks may be counted as a single one. That's when LockService comes in, to protect your logic:
function countClicks()
var r = SpreadsheetApp.getActive().getSheetByName('Sheet1').getRange('B2');
var lock = LockService.getDocumentLock();
lock.waitLock(10000); //throws exception if fails to acquire lock
//you could try-catch it, but that's irrelevant in this example
r.setValue(r.getValue()+1);
SpreadsheetApp.flush(); //forces the script to actually send the values to Sheets
lock.releaseLock();
Hopefully this clarifies it.
By the way, this is just a very lame example. This is not how you should count clicks because, as you've pointed out, locking adds a significant delay in your system. Therefore you should look for alternatives, maybe splitting your data per user or using atomic operations like appendRow.
Thanks. One thing to add is the Web App is deployed as 'Me' but accessible by 'Anyone inc anonymous'. So does this affect my concurrent access concerns and therefore the need for LockService - in that, it is the same user account with many different users.
– MrPea
Mar 7 at 23:11
Really useful. Thankyou
– MrPea
6 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55050648%2fam-i-using-the-google-apps-script-lock-service-correctly%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You do not need to use the LockService if all you're doing is reading data. Therefore, option (a).
There's no need to protect Apps Script or Google Sheets from concurrency, even write operations from the same user. Each parallel access you do from Apps Script runs completely independently from each other, it is a new instance of your app that do not share anything with others, it might even be running on a different server entirely. And Google Sheets handle concurrency just fine, concurrent collaboration is the whole point of the G Suite apps.
So, when do you need LockService?
When your app logic requires such. For example, to protect itself from messing up its own data. Let's say you want to count how many clicks you had and save that number on a sheet, e.g. Sheet1!B2. So your code would look like:
function countClicks()
var r = SpreadsheetApp.getActive().getSheetByName('Sheet1').getRange('B2');
var clicks = r.getValue();
clicks = clicks + 1;
r.setValue(clicks);
If this function runs concurrently, you're not going to corrupt your memory or make Google Sheets break, all that's going to happen is that you might overwrite yourself, as if you had multiple users trying to type in the same cell: the last one wins.
But your logic would be broken, that is, multiple concurrent clicks may be counted as a single one. That's when LockService comes in, to protect your logic:
function countClicks()
var r = SpreadsheetApp.getActive().getSheetByName('Sheet1').getRange('B2');
var lock = LockService.getDocumentLock();
lock.waitLock(10000); //throws exception if fails to acquire lock
//you could try-catch it, but that's irrelevant in this example
r.setValue(r.getValue()+1);
SpreadsheetApp.flush(); //forces the script to actually send the values to Sheets
lock.releaseLock();
Hopefully this clarifies it.
By the way, this is just a very lame example. This is not how you should count clicks because, as you've pointed out, locking adds a significant delay in your system. Therefore you should look for alternatives, maybe splitting your data per user or using atomic operations like appendRow.
Thanks. One thing to add is the Web App is deployed as 'Me' but accessible by 'Anyone inc anonymous'. So does this affect my concurrent access concerns and therefore the need for LockService - in that, it is the same user account with many different users.
– MrPea
Mar 7 at 23:11
Really useful. Thankyou
– MrPea
6 hours ago
add a comment |
You do not need to use the LockService if all you're doing is reading data. Therefore, option (a).
There's no need to protect Apps Script or Google Sheets from concurrency, even write operations from the same user. Each parallel access you do from Apps Script runs completely independently from each other, it is a new instance of your app that do not share anything with others, it might even be running on a different server entirely. And Google Sheets handle concurrency just fine, concurrent collaboration is the whole point of the G Suite apps.
So, when do you need LockService?
When your app logic requires such. For example, to protect itself from messing up its own data. Let's say you want to count how many clicks you had and save that number on a sheet, e.g. Sheet1!B2. So your code would look like:
function countClicks()
var r = SpreadsheetApp.getActive().getSheetByName('Sheet1').getRange('B2');
var clicks = r.getValue();
clicks = clicks + 1;
r.setValue(clicks);
If this function runs concurrently, you're not going to corrupt your memory or make Google Sheets break, all that's going to happen is that you might overwrite yourself, as if you had multiple users trying to type in the same cell: the last one wins.
But your logic would be broken, that is, multiple concurrent clicks may be counted as a single one. That's when LockService comes in, to protect your logic:
function countClicks()
var r = SpreadsheetApp.getActive().getSheetByName('Sheet1').getRange('B2');
var lock = LockService.getDocumentLock();
lock.waitLock(10000); //throws exception if fails to acquire lock
//you could try-catch it, but that's irrelevant in this example
r.setValue(r.getValue()+1);
SpreadsheetApp.flush(); //forces the script to actually send the values to Sheets
lock.releaseLock();
Hopefully this clarifies it.
By the way, this is just a very lame example. This is not how you should count clicks because, as you've pointed out, locking adds a significant delay in your system. Therefore you should look for alternatives, maybe splitting your data per user or using atomic operations like appendRow.
Thanks. One thing to add is the Web App is deployed as 'Me' but accessible by 'Anyone inc anonymous'. So does this affect my concurrent access concerns and therefore the need for LockService - in that, it is the same user account with many different users.
– MrPea
Mar 7 at 23:11
Really useful. Thankyou
– MrPea
6 hours ago
add a comment |
You do not need to use the LockService if all you're doing is reading data. Therefore, option (a).
There's no need to protect Apps Script or Google Sheets from concurrency, even write operations from the same user. Each parallel access you do from Apps Script runs completely independently from each other, it is a new instance of your app that do not share anything with others, it might even be running on a different server entirely. And Google Sheets handle concurrency just fine, concurrent collaboration is the whole point of the G Suite apps.
So, when do you need LockService?
When your app logic requires such. For example, to protect itself from messing up its own data. Let's say you want to count how many clicks you had and save that number on a sheet, e.g. Sheet1!B2. So your code would look like:
function countClicks()
var r = SpreadsheetApp.getActive().getSheetByName('Sheet1').getRange('B2');
var clicks = r.getValue();
clicks = clicks + 1;
r.setValue(clicks);
If this function runs concurrently, you're not going to corrupt your memory or make Google Sheets break, all that's going to happen is that you might overwrite yourself, as if you had multiple users trying to type in the same cell: the last one wins.
But your logic would be broken, that is, multiple concurrent clicks may be counted as a single one. That's when LockService comes in, to protect your logic:
function countClicks()
var r = SpreadsheetApp.getActive().getSheetByName('Sheet1').getRange('B2');
var lock = LockService.getDocumentLock();
lock.waitLock(10000); //throws exception if fails to acquire lock
//you could try-catch it, but that's irrelevant in this example
r.setValue(r.getValue()+1);
SpreadsheetApp.flush(); //forces the script to actually send the values to Sheets
lock.releaseLock();
Hopefully this clarifies it.
By the way, this is just a very lame example. This is not how you should count clicks because, as you've pointed out, locking adds a significant delay in your system. Therefore you should look for alternatives, maybe splitting your data per user or using atomic operations like appendRow.
You do not need to use the LockService if all you're doing is reading data. Therefore, option (a).
There's no need to protect Apps Script or Google Sheets from concurrency, even write operations from the same user. Each parallel access you do from Apps Script runs completely independently from each other, it is a new instance of your app that do not share anything with others, it might even be running on a different server entirely. And Google Sheets handle concurrency just fine, concurrent collaboration is the whole point of the G Suite apps.
So, when do you need LockService?
When your app logic requires such. For example, to protect itself from messing up its own data. Let's say you want to count how many clicks you had and save that number on a sheet, e.g. Sheet1!B2. So your code would look like:
function countClicks()
var r = SpreadsheetApp.getActive().getSheetByName('Sheet1').getRange('B2');
var clicks = r.getValue();
clicks = clicks + 1;
r.setValue(clicks);
If this function runs concurrently, you're not going to corrupt your memory or make Google Sheets break, all that's going to happen is that you might overwrite yourself, as if you had multiple users trying to type in the same cell: the last one wins.
But your logic would be broken, that is, multiple concurrent clicks may be counted as a single one. That's when LockService comes in, to protect your logic:
function countClicks()
var r = SpreadsheetApp.getActive().getSheetByName('Sheet1').getRange('B2');
var lock = LockService.getDocumentLock();
lock.waitLock(10000); //throws exception if fails to acquire lock
//you could try-catch it, but that's irrelevant in this example
r.setValue(r.getValue()+1);
SpreadsheetApp.flush(); //forces the script to actually send the values to Sheets
lock.releaseLock();
Hopefully this clarifies it.
By the way, this is just a very lame example. This is not how you should count clicks because, as you've pointed out, locking adds a significant delay in your system. Therefore you should look for alternatives, maybe splitting your data per user or using atomic operations like appendRow.
edited Mar 12 at 15:14
answered Mar 7 at 22:46
Henrique G. AbreuHenrique G. Abreu
13.9k13955
13.9k13955
Thanks. One thing to add is the Web App is deployed as 'Me' but accessible by 'Anyone inc anonymous'. So does this affect my concurrent access concerns and therefore the need for LockService - in that, it is the same user account with many different users.
– MrPea
Mar 7 at 23:11
Really useful. Thankyou
– MrPea
6 hours ago
add a comment |
Thanks. One thing to add is the Web App is deployed as 'Me' but accessible by 'Anyone inc anonymous'. So does this affect my concurrent access concerns and therefore the need for LockService - in that, it is the same user account with many different users.
– MrPea
Mar 7 at 23:11
Really useful. Thankyou
– MrPea
6 hours ago
Thanks. One thing to add is the Web App is deployed as 'Me' but accessible by 'Anyone inc anonymous'. So does this affect my concurrent access concerns and therefore the need for LockService - in that, it is the same user account with many different users.
– MrPea
Mar 7 at 23:11
Thanks. One thing to add is the Web App is deployed as 'Me' but accessible by 'Anyone inc anonymous'. So does this affect my concurrent access concerns and therefore the need for LockService - in that, it is the same user account with many different users.
– MrPea
Mar 7 at 23:11
Really useful. Thankyou
– MrPea
6 hours ago
Really useful. Thankyou
– MrPea
6 hours ago
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55050648%2fam-i-using-the-google-apps-script-lock-service-correctly%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown