Today I did 50 climbs to raise money for Yorkshire Cancer Research and Diabetes UK.
Total climb between 500m and 750m (as big as one of our local mountains). Time about 6 hours.
justgiving.com/team/richard-…
Here's the code as it finally stood. This is not production code! (It was quick demos of locking patterns for a seminar on locking). The original called publish() immediately rather than storing things up.
Replying to @RichardSoftware @PhilW_SF
My workaround has been to batch up events and fire them at the end of the transaction. I then reconstruct the order on the client from the timestamps.
Replying to @RichardSoftware @PhilW_SF
So I use Platform Events in "Fire Immediately" mode. The allows me to stream debugging information to the front end.
What I'm seeing is that firing the event causes the FOR ACCESS lock to be dropped, but not a DML UPDATE lock.
Yet locks held by DML do not seem to be affected. A test which performed an UPDATE then slept did result in locking exceptions as expected. Note that this code exhibits the race condition. My Node/Postgres demos didn't race all the time, but Apex is easy to make race conditions.
Ouch! I'm writing demos to present on locking in Salesforce and thought I'd use a "publish immediately" platform event for locking.
Firing platform events breaks locks!!!!
Here the demo with logging inline, and again with logging delayed until end of execution.
I'll be doing an internal seminar on Salesforce concurrency. I have a pattern I call "Blind Write" after the "Blind" function on stage lighting desks. It allows the operator to set specific values without seeing the object (call it LightingState__c). But can I use that term here?
This is how I'm creating data. Quite simple. I could get nasty in a future iteration and add covariance or apply a transformation matrix to the results.













