---
id: post/demiliani-com/14031
type: post
title: "Dynamics 365 Business Central: AL transaction isolation levels and cache usage."
summary: Runtime version 11 added Record.ReadIsolation, which overrides a transaction's isolation level for reads on one record instance. The NST record cache only answers Get() calls under Default or ReadUncommitted. ReadCommitted, RepeatableRead and UpdLock send every Get() to SQL Server, which can slow repeated reads a lot. The author argues that RepeatableRead and UpdLock could safely use the cache once the lock is held.
tier: community
language: en
tags:
  - transaction isolation
  - record caching
  - al performance
  - database optimization
  - locking behavior
  - readisolation method
system: development
review:
  state: reviewed
  by: opus
  at: "2026-10-07T23:48:09.664Z"
  flags: []
generated:
  at: "2026-10-07T22:42:12.892Z"
  pipeline: 0.2.0
  prompts:
    extract-post: 1
  input_hash: 74d436a758fbc0e4aed0b1a4e49b2954a1733fd4a6493ac8cb15af3f9e59cba2
evidence:
  - kind: blog
    url: https://demiliani.com/2026/08/05/dynamics-365-business-central-al-transaction-isolation-levels-and-cache-usage/
    title: "Dynamics 365 Business Central: AL transaction isolation levels and cache usage."
    date: "2026-08-05"
    commit: null
    t: null
    quote: null
  - kind: blog
    url: https://demiliani.com/2026/08/05/dynamics-365-business-central-al-transaction-isolation-levels-and-cache-usage/
    title: "Dynamics 365 Business Central: AL transaction isolation levels and cache usage."
    date: "2026-08-05"
    commit: null
    t: null
    quote: The NST record cache only serves Get() calls from cache when ReadIsolation is set to Default or ReadUncommitted.
  - kind: blog
    url: https://demiliani.com/2026/08/05/dynamics-365-business-central-al-transaction-isolation-levels-and-cache-usage/
    title: "Dynamics 365 Business Central: AL transaction isolation levels and cache usage."
    date: "2026-08-05"
    commit: null
    t: null
    quote: Once the isolation level goes up, it stays that way for the whole transaction.
  - kind: blog
    url: https://demiliani.com/2026/08/05/dynamics-365-business-central-al-transaction-isolation-levels-and-cache-usage/
    title: "Dynamics 365 Business Central: AL transaction isolation levels and cache usage."
    date: "2026-08-05"
    commit: null
    t: null
    quote: This can be a measurable performance problem in production BC projects, but only under specific, fairly common conditions.
links:
  learn: []
  objects: []
  features: []
  topics: []
  localizations: []
  videos: []
  posts: []
  guidelines: []
post_id: "14031"
source_id: demiliani-com
source_name: Stefano Demiliani
url: https://demiliani.com/2026/08/05/dynamics-365-business-central-al-transaction-isolation-levels-and-cache-usage/
published_at: "2026-08-05T08:11:52.000Z"
author: Stefano Demiliani
full_text: false
words: 1031
quotes:
  - text: The NST record cache only serves Get() calls from cache when ReadIsolation is set to Default or ReadUncommitted.
    why_it_matters: This is the core insight explaining why higher isolation levels cause dramatic performance degradation, as they bypass caching entirely and force database round-trips.
  - text: Once the isolation level goes up, it stays that way for the whole transaction.
    why_it_matters: This behavior lock-in is critical for developers to understand because it means a single elevated isolation operation affects all subsequent table reads in that transaction.
  - text: This can be a measurable performance problem in production BC projects, but only under specific, fairly common conditions.
    why_it_matters: Highlights that isolation level performance impact is real and should be carefully reviewed in production code, especially for batch operations like order posting.
code_objects_mentioned:
  - other Record.ReadIsolation
  - other Record.GET
  - other Record.FIND
  - other Record.FINDFIRST
  - other Record.FINDSET
  - other Record.COUNT
  - other Record.CALCFIELDS
  - other Record.LockTable
  - other Record.SelectLatestVersion
systems:
  - development
  - platform
  - administration
versions_mentioned:
  - "11"
preview:
  embeddable: true
  frame_url: https://demiliani.com/2026/08/05/dynamics-365-business-central-al-transaction-isolation-levels-and-cache-usage/embed/
  image: https://i0.wp.com/demiliani.com/wp-content/uploads/2026/08/alisolationlevelcache_07.png?fit=1200%2C536&ssl=1
  image_alt: null
  image_w: 1200
  image_h: 536
  site_name: Stefano Demiliani
  favicon: https://demiliani.com/wp-content/uploads/2022/09/sd_wordpress_logo.png?w=32
  probed_at: "2026-10-07T11:50:23.598Z"
---

# Dynamics 365 Business Central: AL transaction isolation levels and cache usage.

[Read the post](https://demiliani.com/2026/08/05/dynamics-365-business-central-al-transaction-isolation-levels-and-cache-usage/) · Stefano Demiliani (Stefano Demiliani, MVP) · 2026-08-05 · 1031 words · tier community · reviewed (checked by Opus)

> Runtime version 11 added Record.ReadIsolation, which overrides a transaction's isolation level for reads on one record instance. The NST record cache only answers Get() calls under Default or ReadUncommitted. ReadCommitted, RepeatableRead and UpdLock send every Get() to SQL Server, which can slow repeated reads a lot. The author argues that RepeatableRead and UpdLock could safely use the cache once the lock is held.

## Key points

- Record.ReadIsolation sets the isolation level for reads on a specific record instance, overriding the transaction's table-level isolation
- Business Central caches records in Global (shared per server instance) and Private (per user and company) caches; Query objects do not use this cache
- Only Default and ReadUncommitted serve Get() from the NST cache; higher levels force a SQL round-trip on every read
- A test reading one Customer record 1000 times showed much slower execution under the higher isolation levels, relevant for scenarios like posting large orders
- On-premises, cache sync between server instances defaults to 30 seconds and can be changed with CacheSynchronizationPeriod in CustomSettings.config

## Quotes

- "The NST record cache only serves Get() calls from cache when ReadIsolation is set to Default or ReadUncommitted." (This is the core insight explaining why higher isolation levels cause dramatic performance degradation, as they bypass caching entirely and force database round-trips.)
- "Once the isolation level goes up, it stays that way for the whole transaction." (This behavior lock-in is critical for developers to understand because it means a single elevated isolation operation affects all subsequent table reads in that transaction.)
- "This can be a measurable performance problem in production BC projects, but only under specific, fairly common conditions." (Highlights that isolation level performance impact is real and should be carefully reviewed in production code, especially for batch operations like order posting.)

## AL objects mentioned

As named in the post. A name that matches one object page by exact type and name links to it; the others stay as named.

- other "Record.ReadIsolation"
- other "Record.GET"
- other "Record.FIND"
- other "Record.FINDFIRST"
- other "Record.FINDSET"
- other "Record.COUNT"
- other "Record.CALCFIELDS"
- other "Record.LockTable"
- other "Record.SelectLatestVersion"

## Context

- Features: Record.ReadIsolation method, Transaction isolation levels, NST record cache, Global and Private caches, Cache synchronization, IsolationLevel option type, Lock behavior on tables, Performance optimization with caching
- Versions: 11

Source: Stefano Demiliani, community blog. Summary, key points and quotes are derived (CONTENT-NOTICE.md); read the original for the full text.