2

Just curious. I know record Ids are not guaranteed to be sequential from the docs. I've also already read this post on what are IDs are composed of.

But lets say 2 or more transactions started at the same time are each inserting 100+ accounts -- is the algorithm advanced enough on its own to guarantee record Id uniqueness , or are insert operations queued somewhere in the order of execution? For example , one guess I have is maybe each transactions' order of execution run in parallel up until some sort of queue during step 7:

Saves the record to the database, but doesn't commit yet.

,where I assume the Ids are generated , and then resumes to running in parallel for all subsequent steps.

Ken K
  • 33
  • 3

1 Answers1

3

In short, yes, ID values will always be unique within an org. An ID may exist in multiple orgs, which happens when you clone an existing org, but the ID will be unique within that org.

What happens is that there's a global pool of ID values somewhere in the pod, and each server in a pod requests a chunk of IDs at a time; these ID values then belong to that server, and no other server in the pod will be assigned that chunk. This is a thread-safe operation.

Next, for each transaction, during the initial database commit (Execution and Order of Operations list after before insert triggers and before after insert triggers), the records are each assigned an ID from the chunk of IDs the server has access to. This is also a thread-safe operation.

This is why ID values are not guaranteed to be sequential, as two different servers in the pod won't have access to the same ID chunks from other servers, so assignment may be chronologically out of order.

Note that the ID values do overlap for each pod, as the pod identifier in the ID is how the values become unique. The first six digits describe the object and origin pod, and the final 12-digits are just a sequential number counter.

sfdcfox
  • 489,769
  • 21
  • 458
  • 806