Apex Code Development You need to sign in to do that
Don't have an account?
matthewGTS Lightning component request boxcarring transaction limits
When the lightning component framework batches together multiple actions, should they execute in the same context and consume the same governor limits? Do they count as a single transaction?
I have a situation where multiple updates are being made separately, and these requests are being batched. The updates are all to the same object type, but the records arent being collected into a list for the flows and triggers. So even though we have bulkified triggers, there is a different trigger execution for each update. That would usually be okay since a list of one record going through a trigger shouldn't exceed any limits. The problem is that all these triggers are in the same execution context, and have to share the limits they would otherwise have to themselves with several other triggers.
Since they share the same limits, I would think they were the same transaction, but an entire transaction should be rolled back if any part of it fails. What I'm seeing is that the updates succeed and are committed up until one of them passes a limit. That update and the ones after it all fail, but the ones that succeeded aren't rolled back. This feels like a bug.
Without rewriting the components to send those individual updates as one list update, how can I avoid hitting limits?
I had asked this question on stack exchange already. I took the suggestion to make the requests send in the background. It works for now, but I know that isn't behavior I can depend on.
I have a situation where multiple updates are being made separately, and these requests are being batched. The updates are all to the same object type, but the records arent being collected into a list for the flows and triggers. So even though we have bulkified triggers, there is a different trigger execution for each update. That would usually be okay since a list of one record going through a trigger shouldn't exceed any limits. The problem is that all these triggers are in the same execution context, and have to share the limits they would otherwise have to themselves with several other triggers.
Since they share the same limits, I would think they were the same transaction, but an entire transaction should be rolled back if any part of it fails. What I'm seeing is that the updates succeed and are committed up until one of them passes a limit. That update and the ones after it all fail, but the ones that succeeded aren't rolled back. This feels like a bug.
Without rewriting the components to send those individual updates as one list update, how can I avoid hitting limits?
I had asked this question on stack exchange already. I took the suggestion to make the requests send in the background. It works for now, but I know that isn't behavior I can depend on.
Sorry for this issue you are encountering.
From what I can tell, it appears that the boxcar effect in Lightning has multiple transactions, but a single governor limit shared across all transactions. It's not in the documentation, which suggests that this might be a bug. For now, consider performing some of the actions as background processes, which inhibits the boxcar effect.
To demonstrate this behavior, I wrote the following code:
Apex:
public class q192876 { @AuraEnabled public static void doAction() { for(Integer i = 0; i < 11; i++) { Contact[] a = [select id from contact limit 1]; } } }Application:<aura:application controller="q192876"> <aura:handler name="init" value="{!this}" action="{!c.init}" /> </aura:application>Controller:({ init: function(component, event, helper) { [1,2,3,4,5,6,7,8,9,10].forEach(function() { var action = component.get("c.doAction"); // action.setBackground(true); $A.enqueueAction(action); }); } })When the code is run as is, it produces a too-many-SOQL error. However, if you uncomment the line in the controller, it instead behaves correctly, producing ten logs instead of 1.
Note that using setBackground(true) means that you're implying that the transaction will take longer, so splitting the transactions will cause a minor delay compared to the boxcar effect.
Thanks,Nagendra