Dynamics 365 Business Central: locking down IsolatedStorage reads.

If you’ve ever used Dynamics 365 Business Central IsolatedStorage object to store module-scoped settings or secret keys in AL, maybe you’ve probably run into a subtle race condition: two sessions read the same key at the same time, both compute a new value, and one of them silently overwrites the other. Nothing throws an error but you just lose an update.

Starting with runtime version 18.0, IsolatedStorage.Get closes that gap. The method now accepts an optional IsolationLevel parameter that controls how the underlying key row is locked while it’s being read.

What changed now?

The new overload looks like this:

var
       MyKey: Text;
       Value, NewValue: SecretText;
    begin
        if IsolatedStorage.Get(MyKey, DataScope::Module, IsolationLevel::UpdLock, Value) then
            IsolatedStorage.Set(MyKey, NewValue, DataScope::Module);

The interesting part is IsolationLevel::UpdLock. Passing it tells the platform to take an update lock on the key’s row for the duration of the read, instead of just reading it under the default isolation semantics. That lock is held until you write the row back (or the transaction ends), so any other session trying to touch the same key has to wait its turn.

In practice, this turns the classic read-modify-write pattern on IsolatedStorage into something you can actually trust inside a single transaction: read the value with UpdLock, compute the new one, call Set and no other process can sneak in between those two steps and read a stale value.

Why this matters?

IsolatedStorage is a common place to keep things like:

• secret keys
• feature flags or per-tenant configuration toggles
• cached tokens or state that needs to survive across sessions

Any of these can be corrupted by concurrent read-modify-write cycles, and until now there was no clean way to protect that pattern without reaching for a full table and explicit locking.

The new isolation level parameter now gives you that protection directly at the IsolatedStorage API level, with a one-line change.

Remember that an update lock isn’t free, but it will block other sessions that try to read or write the same key until your transaction completes. Use UpdLock specifically for the read-modify-write sequences where correctness matters, and stick to the default behavior for plain reads where you don’t intend to write the value back.

This new feature requires runtime version 18.0 or later.

If you’re on an earlier runtime, IsolatedStorage.Get still works, you just won’t have the isolation-level overload available, and you’ll need to fall back to your own locking strategy (or a real table) for the same guarantee.