Timeline for SOQL - concurrent reads of rows when FOR UPDATE clause is used
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 10, 2020 at 15:05 | history | edited | Adrian Larson♦ | CC BY-SA 4.0 |
deleted 77 characters in body
|
| Apr 10, 2020 at 15:03 | comment | added | RedDevil | @identigral - thank you | |
| Apr 10, 2020 at 15:03 | vote | accept | RedDevil | ||
| Apr 10, 2020 at 15:03 | history | edited | RedDevil | CC BY-SA 4.0 |
added identigral comments to answer and marking it as answer
|
| Apr 9, 2020 at 17:58 | comment | added | identigral | It will return an empty result set. | |
| Apr 9, 2020 at 11:47 | comment | added | RedDevil | @identigral - so what happens for my question 2 it returns no records or does it re-query and get another record? | |
| Apr 8, 2020 at 20:06 | comment | added | identigral | Both 1 and 2 (without re-query) are dirty reads...so it sounds like it's behaving similar to a Read Committed isolation level (dirty reads not allowed). | |
| Apr 8, 2020 at 19:32 | comment | added | Adrian Larson♦ |
Yes, another thing to note is that you cannot use both FOR UPDATE and ORDER BY in the same query. So if you want non-arbitrary retrieval, you will need two queries anyway, one to retrieve, then one to lock. If the second query fails, you would rerun the first. Maybe in some type of do/while loop.
|
|
| Apr 8, 2020 at 19:27 | comment | added | RedDevil | thank you, based on question 2 response we may need to re-run the query to get a record. very tricky to understand without documentation | |
| Apr 8, 2020 at 19:23 | history | answered | Adrian Larson♦ | CC BY-SA 4.0 |