2

I was reading about relational databases and found that Salesforce is built on Oracle's Relational Database. Based on my understanding, Relational Databases "promise" the following ACID principle:

  • Atomic: Guarantees that either the entire transaction succeeds or none of it does.

1) What is a "transaction" in Salesforce?

Is this considered one transaction: Say I query a list of Opportunities, I update these Opportunities and run an 'Update' DML on the list. This then triggers some Apex and Flows. Is this all considered ONE transaction?

2) How is Atomicity guaranteed when using Database.Insert or Database.Update that allow for partial success?

3) Is Salesforce fully ACID compliant?

3

Is this considered one transaction: Say I query a list of Opportunities, I update these Opportunities and run an 'Update' DML on the list. This then triggers some Apex and Flows. Is this all considered ONE transaction?

Yes. Without over-complicating things, a transaction is one Debug Log. This could include recursive updates via triggers, etc.

2) How is Atomicity guaranteed when using Database.Insert or Database.Update that allow for partial success?

The records that do not error out are atomically updated. This is useful for situations where you're updating records in bulk, and you want each record to be treated as if it were its own transaction.

For example, if you're updating a list of contacts in the Apex Data Loader, it would be inconvenient if a failure on one record resulted in an error in 199 contacts that are otherwise unrelated, but happened to be in the same transaction.

The allOrNone flag gives the developer the option to treat each record as a separate transaction, or not, without harming performance.

3) Is Salesforce fully ACID compliant?

At a basic level, yes, but it's possible to break ACID intentionally (and this can be a good thing). Aside from Platform Events, which can be dispatched even before a transaction commits, most actions can be rolled back as long as there's a failure.

By default, if a transaction ends with an error or exception, everything that happened is automatically rolled back. Developers can choose to bypass this, but it is an intentional choice that can help improve performance.

From a "purist" point of view, Salesforce is not ACID compliant. There are several ways to cause partial effects despite failure. However, these exceptions to ACID allow better system performance than if ACID was strictly enforced.

| improve this answer | |
  • Thanks for the detailed response! So correct me if I'm wrong but in Salesforce a transaction does not refer to one database transaction but instead refers to an execution context. But doesn't ACID's Atomicity principle only refer to database transactions? Also, you mentioned that if an Apex transaction ends with an error or exception then everything is rolled back. But exceptions can be caught to prevent rollback, so Atomicity isn't guaranteed. Maybe I'm missing something? – AshK Jan 31 at 13:36
  • @AshK A Salesforce transaction is like a database transaction, which can include multiple DML operations. Atomicity speaks to not leaving the database in an inconsistent state with multiple updates (e.g. being able to add a new OrderLineItem but the Order Total does not get updated). A caught exception doesn't rollback a transaction--it did not end in an exception. An uncaught exception that bubbles up to the top causes the rollback. But yes, developers can choose to mishandle exceptions and break Atomicity, which is what I meant by "not fully compliant". – sfdcfox Jan 31 at 13:50
  • @AshK Also, I realize that the example is also part of Consistency, but those are two sides of the same coin. If you can't guarantee Atomicity, you can't guarantee Consistency. The basic Salesforce transaction guarantees both Atomicity and Consistency, but developers can override both. – sfdcfox Jan 31 at 13:52
  • I think what is confusing me is that you mentioned that "The allOrNone flag gives the developer the option to treat each record as a separate transaction"... But you're also saying that an Apex Transaction is like a Database Transaction and that each Apex Transaction = one Debug Log. So this means that each record being processed in Database.Update DML should create a new Debug Log. – AshK Jan 31 at 14:15
  • Also, I always thought that database atomicity is different from Apex transactional atomicity... But you're saying that they're one and the same? – AshK Jan 31 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.