Hey @jamessimone hope you had a nice Thanksgiving! I'm going through Joys of Apex top to bottom again. I noticed you referenced CrudMock_Tests in readme, but I couldn't find it in the source. Am I missing something?

Hey I just read through your blog here about thread-safe reads/writes in Round Robin.

Could you clarify if/how this is truly read/write safe when 2 separate transactions commit at the same time?

The solution seems to use cache timestamps against the repository initialized timestamps when committing, but there's not a mutex/semaphore around preventing 2 repositories from committing at the same time. The platform cache also does not have a semaphore of its own to prevent concurrent reads/writes.

Org cache supports concurrent reads and writes across multiple simultaneous Apex transactions. For example, a transaction updates the key PetName with the value Fido. At the same time, another transaction updates the same key with the value Felix. Both writes succeed, but one of the two values is chosen arbitrarily as the winner, and later transactions read that one value. However, this arbitrary choice is per key rather than per transaction. For example, suppose one transaction writes PetType="Cat" and PetName="Felix". Then, at the same moment, another transaction writes PetType="Dog" and PetName="Fido". In this case, the PetType winning value could be from the first transaction, and the PetName winning value could be from the second transaction. Subsequent get() calls on those keys would return PetType="Cat" and PetName="Fido".

It seems it's possible for 2 repositories to commit at the same time, which would read the same timestamp from the cache, and they would both succeed in committing using the same index.

Is this an edge case that's not covered?

I think a more resolute solution is to do away with the cache/timestamps and instead query the RoundRobin__c record with the FOR UPDATE clause in assignOwners(), do the assignment, update/release the RoundRobin__c for the next thread. You can then implement your recursive retry attempts if the platform throws a DML exception Or make a queueable where the assignOwners() logic chains itself until it succeeds to avoid the recursive limit.

Interesting note from the docs for FOR UPDATE:

If you attempt to lock a record currently locked by another client, your process waits a maximum of 10 seconds for the lock to be released before acquiring a new lock. If the wait time exceeds 10 seconds, a QueryException is thrown. Similarly, if you attempt to update a record currently locked by another client and the lock isn’t released within a maximum of 10 seconds, a DmlException is thrown.