Atomicity requirements and partial execution

[HeikoTheissen]

The specification is unclear about atomicity requirements in data modification requests that allow the continue-on-error preference. OData-Protocol, section 11.7.7.5 says

All requests in a change set represent a single change unit so a service MUST successfully process and apply all the requests in the change set or else apply none of them.

and similar wording is used for the other mass updates that allow the continue-on-error preference (delta update, set-based update, and set-based delete) if that preference is not specified.

This does not imply that all changes must happen in one LUW, but leaves open the option of committing individual changes one after the other and rolling them back if necessary. Indeed, the following sentence seems to encourage this:

It is up to the service implementation to define rollback semantics to undo any requests within a change set that may have been applied before another request in that same change set failed and thereby apply this all-or-nothing requirement.

There may therefore be points in time when a client that reads from the service observes a state where one request from a failed change set has been executed. Is there really no guarantee of atomic data modification requests?

And if the continue-on-error preference is specified, can mass updates always be committed one after the other (like in batch requests without change sets)?

In asynchronous batch requests clients can retrieve the partial result of such a "one-after-the-other" execution, although confusingly not in change sets (despite the second-last paragraph). However, nothing is said about partial results for other asynchronous mass updates that allow the continue-on-error preference, except that

Services MAY include a response body, for example, to provide additional status information.

Can such a response also include the partial result of a "one-after-the-other" execution? Or are such non-batch mass updates always executed in a single LUW (even if continue-on-error is applied)?

[mikepizzo]

Question: Is it allowable behavior for an atomicity set within a batch to start applying changes, where those intermediate changes are visible before the entire atomicity set is complete? Does this change based on the value of continue-on-error?

Outside of the atomicity set, regardless of the setting of continue-on-error, you may see the application of some of the statements.

There may be a difference between the protocol and the service. A banking service that implements the protocol will be transactional. A sports score service may only be eventually consistent.

We would expect the behavior for 11.4.11.1, error handling when updating a collection of entities, to be the same as for batch.

Must be consistent by the time the statement completes?

Conclusion(?): the protocol guarantees that, when the statement completes, either all or none of the statements (within an atomicity group/within a bulk operation) have succeeded or failed. Depending on how the service makes this guarantee, the client may see intermediate results. A transactional service (for example, a bank) will protect against seeing these partial changes, while other services may not require this level of transactional consistency.

Question: do we need some annotation for the service to report their behavior? at what level? can a client request a particular level? OData V5?

[HeikoTheissen]

As a consequence, a request for updating a collection of entities with continue-on-error preference may write its updates to the data storage one by one. If the request also has the respond-async preference, would the following be allowed?

After the successful execution of the update entity list request (A) the response is returned in the body of a response to an interrogation request (B1) against the status monitor resource URL.
If the original request A has not succesfully updated all of the entities, the status monitor returns the successfully updated entities and a next-link to the response for the not (yet) updated entities:

• The response to B1 contains the successfully updated entities and a next-link (for a request B2 for the remaining entities) to the status monitor resource.
• The response to B2 contains the by now successfully updated entity from the remaining “erroneous” entities and a next-link (for a request B3) to the status monitor resource.
• This continues until the all entities have been updated successfully or the server gives up and returns data-modification-errors for the remaining entities.

[HeikoTheissen]

would the following be allowed?

TC 2025-07-30: Yes