Scripted business rule race conditions - how to avoid?

[jimjim]

The lack of transaction isolation in business rules is resulting in a lot of race conditions in our system, and we're not sure how best to resolve.

As one example - we have a Master:Detail where the status of the master record needs to sometimes change based on the status of one or more detail records. We have a business rule that runs when a detail record is changed that updates the master record, which works correctly under low load.

However even with only a dozen concurrent users we're finding that business rules are running concurrently and writing over the top of each other. Since there's no transaction isolation, we're finding the last rules to save is often running off out of date data.

We're also finding that `GlideRecord.update()` will actually re-create the record if it was deleted in another transaction. Even if a business rule checks to make sure the record exists before it runs, the record may have been deleted by the time the rule commits its changes and its therefore re-created, leaving a lot of users confused why records sometimes mysteriously reappear after deletion.

In other systems I've used, transaction isolation prevents these problems from occurring in the first place. Since this isn't available in ServiceNow, how do developers normally deal with these kinds of issues and prevent race conditions? Are there any tricks or best practices for working around this?

[jimjim]

Thanks. Unfortunately in this case it's not that multiple users are updating a single record, but that business rules are conflicting with each other due to the lack of transaction isolation.