The 50,000 row query limit is not actually a “per APEX call” as widely believedHow to turn boxcarring OFF for LWC imperative apex method calls?Maximum number of records retrieved by one SOQL query in a lightning Apex backend controller50,000 query row governor limitDoes the query cursor limit matter if I'm only returning a single row?Apex governor limit warning emailsWhy does it say my SOQL for loop returned 50,001 records when it broke the loop after 20k?Design practises against 50,000 row limitFirst error: Too many query rows: 50001 in a batch apex class without any inner queryAggregated Query Too many query rowsToo many query rows: 50001 in export csvWhat are the limitations of number of Rows that can be returned in an Aura Enabled APEX Method?refreshApex in LWC not working outside of Apex method call promise?

Is the first page of Novel really that important?

How to understand "...to hide the evidence of mishandled magic, or else hidden by castle-proud house-elves" in this sentence

Does WSL2 runs Linux in a virtual machine or alongside windows Kernel?

Why have both: BJT and FET transistors on IC output?

Accurately recalling the key - can everyone do it?

Do moonless nights cause dim light to become darkness, and bright light (e.g. from torches) to become dim light?

In a KP-K endgame, if the enemy king is in front of the pawn, is it always a draw?

Can I say "Gesundheit" if someone is coughing?

Who's behind community AMIs on Amazon EC2?

Can't understand an ACT practice problem: Triangle appears to be isosceles, why isn't the answer 7.3~ here?

Is this popular optical illusion made of a grey-scale image with coloured lines?

How to avoid a lengthy conversation with someone from the neighborhood I don't share interests with

Does a bard know when a character uses their Bardic Inspiration?

Is it uncompelling to continue the story with lower stakes?

Speaker impedance: rewiring four 8 Ω speakers for use with 8 Ω amp output

Astable 555 circuit not oscillating

Confused over role of 「自分が」in this particular passage

What is a summary of basic Jewish metaphysics or theology?

Skipping same old introductions

How to call made-up data?

Is there a word that describes people who are extraverted and/or energetic, but uneducated, unintelligent and/or uncreative?

Why wasn't interlaced CRT scanning done back and forth?

Current in only inductive AC circuit

What is the reason behind water not falling from a bucket at the top of loop?



The 50,000 row query limit is not actually a “per APEX call” as widely believed


How to turn boxcarring OFF for LWC imperative apex method calls?Maximum number of records retrieved by one SOQL query in a lightning Apex backend controller50,000 query row governor limitDoes the query cursor limit matter if I'm only returning a single row?Apex governor limit warning emailsWhy does it say my SOQL for loop returned 50,001 records when it broke the loop after 20k?Design practises against 50,000 row limitFirst error: Too many query rows: 50001 in a batch apex class without any inner queryAggregated Query Too many query rowsToo many query rows: 50001 in export csvWhat are the limitations of number of Rows that can be returned in an Aura Enabled APEX Method?refreshApex in LWC not working outside of Apex method call promise?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








1















I recently ran into a strange issue with the 50,000 row query limit that had me puzzled due to the belief that the 50,000 row query limit applied only per-call.



This realization occurred while writing a LWC where the .js file calls apex methods to gather data. Specifically, in this instance, I was creating a custom table that displays some aggregated data and only loads and displays 5 rows at time. Users can page through the table to load and display 5 more items.



Whenever I am loading a table page, the JS side makes 5 separate calls (one for each row) to the same APEX method to gather all the aggregated data. I actually use a Promise to send off all 5 calls at one time.



Inside of this reused APEX method is a few queries that get about 2500 rows combined MAX. This apex method does not query over 2500 rows per-call in any case.



When JS uses a promise to send off 5 of these calls at once, I have no problem. However, I also allow users to download the entire table into a csv. When they hit this button, JS uses the same APEX method to load the data, but this part requires JS to put more than 5 calls to the same method in the Promise that gathers all the data. If the table is 10 pages, it ends up putting 50 calls to the same APEX method in the same promise. This is when I get the 50,000 query limit reached error.



This has me confused because I thought that a single call to an APEX method can't query over 50,000 rows... After playing around a little, I noticed that the error would occur once I tried to load more than 20 rows. 19 rows worked fine because 19 * 2500 < 50,000. But 21 rows errored because 21* 2500 > 50,000.



Therefore, I believe that the 50,000 query limit isn't calculated per APEX Method call, but rather calculated on the total number of simultaneous calls to the same APEX method.










share|improve this question



















  • 5





    It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.

    – Programmatic
    Jul 24 at 15:31






  • 2





    See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.

    – David Reed
    Jul 24 at 15:33






  • 2





    @DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.

    – sfdcfox
    Jul 24 at 15:34






  • 2





    @sfdcfox , DavidReed answerception.

    – Pranay Jaiswal
    Jul 24 at 15:37

















1















I recently ran into a strange issue with the 50,000 row query limit that had me puzzled due to the belief that the 50,000 row query limit applied only per-call.



This realization occurred while writing a LWC where the .js file calls apex methods to gather data. Specifically, in this instance, I was creating a custom table that displays some aggregated data and only loads and displays 5 rows at time. Users can page through the table to load and display 5 more items.



Whenever I am loading a table page, the JS side makes 5 separate calls (one for each row) to the same APEX method to gather all the aggregated data. I actually use a Promise to send off all 5 calls at one time.



Inside of this reused APEX method is a few queries that get about 2500 rows combined MAX. This apex method does not query over 2500 rows per-call in any case.



When JS uses a promise to send off 5 of these calls at once, I have no problem. However, I also allow users to download the entire table into a csv. When they hit this button, JS uses the same APEX method to load the data, but this part requires JS to put more than 5 calls to the same method in the Promise that gathers all the data. If the table is 10 pages, it ends up putting 50 calls to the same APEX method in the same promise. This is when I get the 50,000 query limit reached error.



This has me confused because I thought that a single call to an APEX method can't query over 50,000 rows... After playing around a little, I noticed that the error would occur once I tried to load more than 20 rows. 19 rows worked fine because 19 * 2500 < 50,000. But 21 rows errored because 21* 2500 > 50,000.



Therefore, I believe that the 50,000 query limit isn't calculated per APEX Method call, but rather calculated on the total number of simultaneous calls to the same APEX method.










share|improve this question



















  • 5





    It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.

    – Programmatic
    Jul 24 at 15:31






  • 2





    See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.

    – David Reed
    Jul 24 at 15:33






  • 2





    @DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.

    – sfdcfox
    Jul 24 at 15:34






  • 2





    @sfdcfox , DavidReed answerception.

    – Pranay Jaiswal
    Jul 24 at 15:37













1












1








1








I recently ran into a strange issue with the 50,000 row query limit that had me puzzled due to the belief that the 50,000 row query limit applied only per-call.



This realization occurred while writing a LWC where the .js file calls apex methods to gather data. Specifically, in this instance, I was creating a custom table that displays some aggregated data and only loads and displays 5 rows at time. Users can page through the table to load and display 5 more items.



Whenever I am loading a table page, the JS side makes 5 separate calls (one for each row) to the same APEX method to gather all the aggregated data. I actually use a Promise to send off all 5 calls at one time.



Inside of this reused APEX method is a few queries that get about 2500 rows combined MAX. This apex method does not query over 2500 rows per-call in any case.



When JS uses a promise to send off 5 of these calls at once, I have no problem. However, I also allow users to download the entire table into a csv. When they hit this button, JS uses the same APEX method to load the data, but this part requires JS to put more than 5 calls to the same method in the Promise that gathers all the data. If the table is 10 pages, it ends up putting 50 calls to the same APEX method in the same promise. This is when I get the 50,000 query limit reached error.



This has me confused because I thought that a single call to an APEX method can't query over 50,000 rows... After playing around a little, I noticed that the error would occur once I tried to load more than 20 rows. 19 rows worked fine because 19 * 2500 < 50,000. But 21 rows errored because 21* 2500 > 50,000.



Therefore, I believe that the 50,000 query limit isn't calculated per APEX Method call, but rather calculated on the total number of simultaneous calls to the same APEX method.










share|improve this question














I recently ran into a strange issue with the 50,000 row query limit that had me puzzled due to the belief that the 50,000 row query limit applied only per-call.



This realization occurred while writing a LWC where the .js file calls apex methods to gather data. Specifically, in this instance, I was creating a custom table that displays some aggregated data and only loads and displays 5 rows at time. Users can page through the table to load and display 5 more items.



Whenever I am loading a table page, the JS side makes 5 separate calls (one for each row) to the same APEX method to gather all the aggregated data. I actually use a Promise to send off all 5 calls at one time.



Inside of this reused APEX method is a few queries that get about 2500 rows combined MAX. This apex method does not query over 2500 rows per-call in any case.



When JS uses a promise to send off 5 of these calls at once, I have no problem. However, I also allow users to download the entire table into a csv. When they hit this button, JS uses the same APEX method to load the data, but this part requires JS to put more than 5 calls to the same method in the Promise that gathers all the data. If the table is 10 pages, it ends up putting 50 calls to the same APEX method in the same promise. This is when I get the 50,000 query limit reached error.



This has me confused because I thought that a single call to an APEX method can't query over 50,000 rows... After playing around a little, I noticed that the error would occur once I tried to load more than 20 rows. 19 rows worked fine because 19 * 2500 < 50,000. But 21 rows errored because 21* 2500 > 50,000.



Therefore, I believe that the 50,000 query limit isn't calculated per APEX Method call, but rather calculated on the total number of simultaneous calls to the same APEX method.







query lightning-web-components governorlimits






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jul 24 at 15:28









BlondeSwanBlondeSwan

3941 silver badge12 bronze badges




3941 silver badge12 bronze badges










  • 5





    It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.

    – Programmatic
    Jul 24 at 15:31






  • 2





    See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.

    – David Reed
    Jul 24 at 15:33






  • 2





    @DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.

    – sfdcfox
    Jul 24 at 15:34






  • 2





    @sfdcfox , DavidReed answerception.

    – Pranay Jaiswal
    Jul 24 at 15:37












  • 5





    It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.

    – Programmatic
    Jul 24 at 15:31






  • 2





    See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.

    – David Reed
    Jul 24 at 15:33






  • 2





    @DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.

    – sfdcfox
    Jul 24 at 15:34






  • 2





    @sfdcfox , DavidReed answerception.

    – Pranay Jaiswal
    Jul 24 at 15:37







5




5





It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.

– Programmatic
Jul 24 at 15:31





It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.

– Programmatic
Jul 24 at 15:31




2




2





See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.

– David Reed
Jul 24 at 15:33





See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.

– David Reed
Jul 24 at 15:33




2




2





@DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.

– sfdcfox
Jul 24 at 15:34





@DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.

– sfdcfox
Jul 24 at 15:34




2




2





@sfdcfox , DavidReed answerception.

– Pranay Jaiswal
Jul 24 at 15:37





@sfdcfox , DavidReed answerception.

– Pranay Jaiswal
Jul 24 at 15:37










2 Answers
2






active

oldest

votes


















5














Aura, and LWC, groups several requests together in order to maximize performance. This is called "boxcar'ing" (or boxcarring) in the documentation. All Apex requests in the same boxcar payload are subject to a single set of governor limits, even though they're allowed to fail/succeed independently. This means you need to make sure you don't place DML before callout operation requests, and you'll want to limit the number of requests you perform simultaneously. This is documented behavior and has existed since the beginning of Lightning.






share|improve this answer



























  • Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks

    – BlondeSwan
    Jul 24 at 15:36






  • 1





    @BlondeSwan I think its from VF days. It was called as buffer in remoting . Whether to group requests executed close to each other in time into a single request. The default is true.

    – Pranay Jaiswal
    Jul 24 at 15:39






  • 5





    In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.

    – Phil W
    Jul 24 at 15:58











  • @PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.

    – sfdcfox
    Jul 24 at 16:06


















3














Its called as boxcarring, Salesforce bundles multiple request in to 1 to save repeated calls to server.



You can seee from Debug logs, only one is created.



A quick solution is to add a timeout or use the promise chain while calling apex. In this way , each apex call will be treated as new transaction and those limits get reset.



new Promise(function(resolve, reject) 

setTimeout(() => resolve(1), 1000); // (*)

).then(function(result) // (**)

alert(result); // 1
return result * 2;

).then(function(result) // (***)

alert(result); // 2
return result * 2;

).then(function(result)

alert(result); // 4
return result * 2;

);


Box carring also has side-effect of slowing initial loading down. read more here.






share|improve this answer

























  • There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.

    – Phil W
    Jul 24 at 16:05













Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "459"
;
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f270842%2fthe-50-000-row-query-limit-is-not-actually-a-per-apex-call-as-widely-believed%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









5














Aura, and LWC, groups several requests together in order to maximize performance. This is called "boxcar'ing" (or boxcarring) in the documentation. All Apex requests in the same boxcar payload are subject to a single set of governor limits, even though they're allowed to fail/succeed independently. This means you need to make sure you don't place DML before callout operation requests, and you'll want to limit the number of requests you perform simultaneously. This is documented behavior and has existed since the beginning of Lightning.






share|improve this answer



























  • Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks

    – BlondeSwan
    Jul 24 at 15:36






  • 1





    @BlondeSwan I think its from VF days. It was called as buffer in remoting . Whether to group requests executed close to each other in time into a single request. The default is true.

    – Pranay Jaiswal
    Jul 24 at 15:39






  • 5





    In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.

    – Phil W
    Jul 24 at 15:58











  • @PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.

    – sfdcfox
    Jul 24 at 16:06















5














Aura, and LWC, groups several requests together in order to maximize performance. This is called "boxcar'ing" (or boxcarring) in the documentation. All Apex requests in the same boxcar payload are subject to a single set of governor limits, even though they're allowed to fail/succeed independently. This means you need to make sure you don't place DML before callout operation requests, and you'll want to limit the number of requests you perform simultaneously. This is documented behavior and has existed since the beginning of Lightning.






share|improve this answer



























  • Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks

    – BlondeSwan
    Jul 24 at 15:36






  • 1





    @BlondeSwan I think its from VF days. It was called as buffer in remoting . Whether to group requests executed close to each other in time into a single request. The default is true.

    – Pranay Jaiswal
    Jul 24 at 15:39






  • 5





    In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.

    – Phil W
    Jul 24 at 15:58











  • @PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.

    – sfdcfox
    Jul 24 at 16:06













5












5








5







Aura, and LWC, groups several requests together in order to maximize performance. This is called "boxcar'ing" (or boxcarring) in the documentation. All Apex requests in the same boxcar payload are subject to a single set of governor limits, even though they're allowed to fail/succeed independently. This means you need to make sure you don't place DML before callout operation requests, and you'll want to limit the number of requests you perform simultaneously. This is documented behavior and has existed since the beginning of Lightning.






share|improve this answer















Aura, and LWC, groups several requests together in order to maximize performance. This is called "boxcar'ing" (or boxcarring) in the documentation. All Apex requests in the same boxcar payload are subject to a single set of governor limits, even though they're allowed to fail/succeed independently. This means you need to make sure you don't place DML before callout operation requests, and you'll want to limit the number of requests you perform simultaneously. This is documented behavior and has existed since the beginning of Lightning.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jul 24 at 16:07









Phil W

2,6501 gold badge3 silver badges12 bronze badges




2,6501 gold badge3 silver badges12 bronze badges










answered Jul 24 at 15:33









sfdcfoxsfdcfox

281k14 gold badges227 silver badges480 bronze badges




281k14 gold badges227 silver badges480 bronze badges















  • Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks

    – BlondeSwan
    Jul 24 at 15:36






  • 1





    @BlondeSwan I think its from VF days. It was called as buffer in remoting . Whether to group requests executed close to each other in time into a single request. The default is true.

    – Pranay Jaiswal
    Jul 24 at 15:39






  • 5





    In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.

    – Phil W
    Jul 24 at 15:58











  • @PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.

    – sfdcfox
    Jul 24 at 16:06

















  • Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks

    – BlondeSwan
    Jul 24 at 15:36






  • 1





    @BlondeSwan I think its from VF days. It was called as buffer in remoting . Whether to group requests executed close to each other in time into a single request. The default is true.

    – Pranay Jaiswal
    Jul 24 at 15:39






  • 5





    In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.

    – Phil W
    Jul 24 at 15:58











  • @PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.

    – sfdcfox
    Jul 24 at 16:06
















Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks

– BlondeSwan
Jul 24 at 15:36





Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks

– BlondeSwan
Jul 24 at 15:36




1




1





@BlondeSwan I think its from VF days. It was called as buffer in remoting . Whether to group requests executed close to each other in time into a single request. The default is true.

– Pranay Jaiswal
Jul 24 at 15:39





@BlondeSwan I think its from VF days. It was called as buffer in remoting . Whether to group requests executed close to each other in time into a single request. The default is true.

– Pranay Jaiswal
Jul 24 at 15:39




5




5





In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.

– Phil W
Jul 24 at 15:58





In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.

– Phil W
Jul 24 at 15:58













@PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.

– sfdcfox
Jul 24 at 16:06





@PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.

– sfdcfox
Jul 24 at 16:06













3














Its called as boxcarring, Salesforce bundles multiple request in to 1 to save repeated calls to server.



You can seee from Debug logs, only one is created.



A quick solution is to add a timeout or use the promise chain while calling apex. In this way , each apex call will be treated as new transaction and those limits get reset.



new Promise(function(resolve, reject) 

setTimeout(() => resolve(1), 1000); // (*)

).then(function(result) // (**)

alert(result); // 1
return result * 2;

).then(function(result) // (***)

alert(result); // 2
return result * 2;

).then(function(result)

alert(result); // 4
return result * 2;

);


Box carring also has side-effect of slowing initial loading down. read more here.






share|improve this answer

























  • There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.

    – Phil W
    Jul 24 at 16:05















3














Its called as boxcarring, Salesforce bundles multiple request in to 1 to save repeated calls to server.



You can seee from Debug logs, only one is created.



A quick solution is to add a timeout or use the promise chain while calling apex. In this way , each apex call will be treated as new transaction and those limits get reset.



new Promise(function(resolve, reject) 

setTimeout(() => resolve(1), 1000); // (*)

).then(function(result) // (**)

alert(result); // 1
return result * 2;

).then(function(result) // (***)

alert(result); // 2
return result * 2;

).then(function(result)

alert(result); // 4
return result * 2;

);


Box carring also has side-effect of slowing initial loading down. read more here.






share|improve this answer

























  • There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.

    – Phil W
    Jul 24 at 16:05













3












3








3







Its called as boxcarring, Salesforce bundles multiple request in to 1 to save repeated calls to server.



You can seee from Debug logs, only one is created.



A quick solution is to add a timeout or use the promise chain while calling apex. In this way , each apex call will be treated as new transaction and those limits get reset.



new Promise(function(resolve, reject) 

setTimeout(() => resolve(1), 1000); // (*)

).then(function(result) // (**)

alert(result); // 1
return result * 2;

).then(function(result) // (***)

alert(result); // 2
return result * 2;

).then(function(result)

alert(result); // 4
return result * 2;

);


Box carring also has side-effect of slowing initial loading down. read more here.






share|improve this answer













Its called as boxcarring, Salesforce bundles multiple request in to 1 to save repeated calls to server.



You can seee from Debug logs, only one is created.



A quick solution is to add a timeout or use the promise chain while calling apex. In this way , each apex call will be treated as new transaction and those limits get reset.



new Promise(function(resolve, reject) 

setTimeout(() => resolve(1), 1000); // (*)

).then(function(result) // (**)

alert(result); // 1
return result * 2;

).then(function(result) // (***)

alert(result); // 2
return result * 2;

).then(function(result)

alert(result); // 4
return result * 2;

);


Box carring also has side-effect of slowing initial loading down. read more here.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jul 24 at 15:35









Pranay JaiswalPranay Jaiswal

23.1k5 gold badges33 silver badges74 bronze badges




23.1k5 gold badges33 silver badges74 bronze badges















  • There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.

    – Phil W
    Jul 24 at 16:05

















  • There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.

    – Phil W
    Jul 24 at 16:05
















There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.

– Phil W
Jul 24 at 16:05





There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.

– Phil W
Jul 24 at 16:05

















draft saved

draft discarded
















































Thanks for contributing an answer to Salesforce Stack Exchange!


  • 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.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f270842%2fthe-50-000-row-query-limit-is-not-actually-a-per-apex-call-as-widely-believed%23new-answer', 'question_page');

);

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







Popular posts from this blog

Get product attribute by attribute group code in magento 2get product attribute by product attribute group in magento 2Magento 2 Log Bundle Product Data in List Page?How to get all product attribute of a attribute group of Default attribute set?Magento 2.1 Create a filter in the product grid by new attributeMagento 2 : Get Product Attribute values By GroupMagento 2 How to get all existing values for one attributeMagento 2 get custom attribute of a single product inside a pluginMagento 2.3 How to get all the Multi Source Inventory (MSI) locations collection in custom module?Magento2: how to develop rest API to get new productsGet product attribute by attribute group code ( [attribute_group_code] ) in magento 2

Category:9 (number) SubcategoriesMedia in category "9 (number)"Navigation menuUpload mediaGND ID: 4485639-8Library of Congress authority ID: sh85091979ReasonatorScholiaStatistics

Magento 2.3: How do i solve this, Not registered handle, on custom form?How can i rewrite TierPrice Block in Magento2magento 2 captcha not rendering if I override layout xmlmain.CRITICAL: Plugin class doesn't existMagento 2 : Problem while adding custom button order view page?Magento 2.2.5: Overriding Admin Controller sales/orderMagento 2.2.5: Add, Update and Delete existing products Custom OptionsMagento 2.3 : File Upload issue in UI Component FormMagento2 Not registered handleHow to configured Form Builder Js in my custom magento 2.3.0 module?Magento 2.3. How to create image upload field in an admin form