If the lightning component framework batches together multiple update requests, are they all subject to the rules and limits of a single transaction?
The framework queues up actions before sending them to the server. This mechanism is largely transparent to you when you’re writing code but it enables the framework to minimize network traffic by batching multiple actions into one request (XHR).
The batching of actions is also known as boxcar’ing, similar to a train that couples boxcars together.
From Apex Transactions:
An Apex transaction represents a set of operations that are executed as a single unit. All DML operations in a transaction either complete successfully, or if an error occurs in one operation, the entire transaction is rolled back and no data is committed to the database. The boundary of a transaction can be a trigger, a class method, an anonymous block of code, a Visualforce page, or a custom Web service method.
We just encountered a situation that seems to suggest that the multiple updates will execute in one context with a single transaction's limits, but does not rollback all of them when a limit exception occurs.
We have a component that displays an Event and allows user to approve or remove. If the Event is removed, then a process-builder flow will delete all the child Participant objects for that Event.
Events are children of Courses, and we have another component to display a Course, which includes a list of the Event components. The Course component has a "Remove All" button that loops through the Event components and calls the Remove method. So each Event should have a separate update request, and the requests will probably be boxcar'd together.
However, when using this "Remove All" button on a Course that has several Events, we exceed the 100 SOQL query limit. Looking at the debug logs, there was a flow started for each individual Event. The first four of these flows were able to complete successfully before the limit was reached. Those first four Events come out of this with their decision updated to "Remove" and their Participants deleted. The rest of the Events are not updated, and still have their Participants.
So if they were all under the same transaction context, sharing the same limits, then why were some of them able to update? Shouldn't they all have been rolled back when the governor limit was reached?
Note: The limit exception doesn't normally happen when making this update. Modifying multiple Events through apex or a list view consumes the same number of queries as updating a single Event. In those cases the flow collects all the Events together and operates on the list.