Gerardo Rentería Blog

2023 Wave 2 – v23: Feature Tri-State locking in AL (English Version)

2023 Wave 2 – v23: Característica Bloqueo en AL Tri-Estado

El objetivo de esta funcionalidad que nos trae este Wave 2 del 2023 (v23) es mejorar el rendimiento y la concurrencia de las transacciones de la base de datos. Performance gain by reducing locks in the database

Esta función permite operaciones de lectura optimistas que continuan a operaciones de escritura, en lugar de una concurrencia disminuida y una coherencia rigurosa. De tal manera, los clientes pueden prever un aumento de la concurrencia evitando accesos a datos fallidos con bloqueos.

¿Por qué?

Al analizar los problemas de rendimiento de Business Central, se hace evidente que las interacciones con la base de datos son casi siempre el aspecto más costoso de cualquier operación.

Muchos usuarios cada día obtienen como respuesta errores en sus operaciones debido a la espera de bloqueos de datos. Las estadísticas de SaaS Business Central muestran que la lectura de datos, y no su modificación, representa casi el 50% de todos los bloqueos.

Comportamiento

Primero algo de teoría, ¿Qué es una sugerencia de tabla (table hint)? Table Hints (Transact-SQL) – SQL Server | Microsoft Learn

Las sugerencias de tabla se utilizan en la sentencia del lenguaje de manipulación de datos (DML) para anular el comportamiento predeterminado del optimizador de consultas. Se puede especificar una estrategia de bloqueo, uno o varios índices, una acción de procesamiento de consultas como una búsqueda de índices o un escaneo de tablas, u otras opciones.

Hasta ahora el comportamiento de bloqueo involucraba 2 estados:

1. Mientras no haya escrituras en la tabla en la transacción actual ni llamadas a LockTable en los registros de la tabla, todas las lecturas irán acompañadas de la sugerencia READUNCOMMITTED. Este es el valor por defecto para todas las lecturas en Business Central y el único nivel de aislamiento de transacciones que permite lecturas sucias.
2. La sugerencia UPDLOCK se aplicará a las lecturas posteriores si se han realizado escrituras en la tabla (o se ha llamado a LockTable en un registro de la misma tabla) en la transacción actual. Por lo que pueden surgir conflictos con otros usuarios si intentan ver o modificar la misma tabla de la transacción actual hasta que confirme o revierta los cambios porque bloquea los datos con un bloqueo exclusivo.

Pero es importante considerar que del análisis del código AL actual se desprende que la mayoría de las lecturas que siguen a las escrituras no guardan relación alguna; en la mayoría de los casos, las lecturas y escrituras son conceptualmente distintas entre sí, y con frecuencia afectan a filas diferentes. Por lo que podría considerarse como una forma de tratar las transacciones mejorable.

// locking behavior in versions 22 (and earlier)
trigger OnAction()
var
    currency1: Record Currency;
    currency2: Record Currency;    
begin
    currency1.FindFirst(); // SQL statement use READUNCOMMITTED

    currency1.Code := 'DKK';
    currency1."ISO Code" := 'DKK';
    currency1.Symbol := 'Kr';
    currency1.Insert();

    currency2.FindLast(); // SQL statement use UPDLOCK (so locks data with an exclusive lock)
end;

El nuevo comportamiento de bloqueo añade un tercero estado entre los dos estados anteriores mencionados, considerando entonces 3 estados:

1. Mientras no haya escrituras en la tabla en la transacción actual ni llamadas a LockTable en los registros de la tabla, todas las lecturas irán acompañadas de la sugerencia READUNCOMMITTED. Este es el valor por defecto para todas las lecturas en Business Central y el único nivel de aislamiento de transacciones que permite lecturas sucias.
2. La sugerencia READCOMMITTED se añadirá a las lecturas posteriores si se han realizado escrituras en la tabla en la transacción actual. Permite que varias sesiones lean y escriban simultáneamente en la misma tabla, siempre que sus modificaciones no choquen entre sí, porque bloquea los datos con un bloqueo compartido (S).
3. La sugerencia UPDLOCK se aplicará a las lecturas posteriores si se ha llamado a LockTable en un registro de esta tabla. Pueden surgir conflictos con otros usuarios si intentan ver o modificar la misma tabla de la transacción actual hasta que confirme o revierta los cambios porque bloquea los datos con un bloqueo exclusivo (X).

Sin duda, la espera de bloqueos ocupa una gran parte del tiempo de procesamiento, por lo que esta nuevo comportamiento propuesto es sin duda una mejora muy importante.

// locking behaviour with tri-state locking
trigger OnAction()
var
    currency1: Record Currency;
    currency2: Record Currency;    
begin
    currency1.FindFirst(); // SQL statement use READUNCOMMITTED

    currency1.Code := 'DKK';
    currency1."ISO Code" := 'DKK';
    currency1.Symbol := 'Kr';
    currency1.Insert();

    currency2.FindLast(); // SQL statement use READCOMMITTED (so locks data with a shared lock)
end;

Habilitación

• Saas: No es necesario hacer nada para activar esta mejora en los nuevos entornos generados en la versión 23.0 y posteriores; la versión 23.0 la activará por defecto. Puede habilitar y deshabilitar la funcionalidad a través de la página de características. Los usuarios verán los cambios la próxima vez que se conecten a Business Central.
• OnPremise: El parámetro EnableTriStateLocking de la configuración del servidor también debe estar establecido en true para activar este tipo de bloqueo. Business Central Server Instance Settings

Recomendaciones

Es muy probable que algunas de sus extensiones deban ajustarse para que implementen el nuevo comportamiento de bloqueo.

Por lo tanto, se aconseja que pruebe sus extensiones previamente. Para ello, copie el entorno de producción en un sandbox, habilite la funcionalidad, pruebe, revise y realice los ajustes de código necesarios.

Luego con seguridad, habilítelo en producción y mejore el rendimiento de sus transacciones.

---

Esto se traduce en menos errores e interrupciones por problemas relacionados con el bloqueo, lo que hace que Business Central sea más rápido y fácil de usar.

Quienes tengan conjuntos de datos grandes o complejos o quienes ejecuten operaciones frecuentes e intensivas en sus servicios en línea se beneficiarán especialmente de esta mejora.

Espero que esta información te ayude.

---

2023 Wave 2 – v23: Feature Tri-State locking in AL

The objective of this functionality in 2023 Wave 2 (v23) is to improve the performance and concurrency of database transactions. Performance gain by reducing locks in the database

This feature allows optimistic read operations to follow write operations, rather than decreased concurrency and strict consistency. In this way, clients can anticipate an increase in concurrency by avoiding failed data accesses with deadlocks.

¿Why?

When analyzing Business Central performance issues, it becomes apparent that database interactions are almost always the most costly aspect of any operation.

Many users every day experience errors in their operations due to waiting for data locks. SaaS Business Central statistics show that reading data, not modifying it, accounts for almost 50% of all deadlocks.

Behavior

First some theory, what is a table hint? Table Hints (Transact-SQL) – SQL Server | Microsoft Learn

Table hints are used in the Data Manipulation Language (DML) statement to override the default behavior of the query optimizer. You can specify a locking strategy, one or more indexes, a query processing action such as an index lookup or a table scan, or other options.

Up to now, the blocking behavior involved 2 states:

1. As long as there are no writes to the table in the current transaction and no LockTable calls on the table records, all reads will be accompanied by the READUNCOMMITTED hint. This is the default value for all reads in Business Central and the only level of transaction isolation that allows dirty reads.
2. The UPDLOCK hint will be applied to subsequent reads if writes have been made to the table (or LockTable has been called on a record in the same table) in the current transaction. So conflicts may arise with other users if they try to view or modify the same table in the current transaction until you commit or roll back the changes because it locks the data with a exclusive lock (X).

But it is important to consider that from the analysis of the current AL code it appears that most of the reads following the writes are unrelated; in most cases, reads and writes are conceptually distinct from each other, and often affect different rows. So it could be considered as a way of dealing with transactions that could be improved.

// locking behavior in versions 22 (and earlier)
trigger OnAction()
var
    currency1: Record Currency;
    currency2: Record Currency;    
begin
    currency1.FindFirst(); // SQL statement use READUNCOMMITTED

    currency1.Code := 'DKK';
    currency1."ISO Code" := 'DKK';
    currency1.Symbol := 'Kr';
    currency1.Insert();

    currency2.FindLast(); // SQL statement use UPDLOCK (so locks data with an exclusive lock)
end;

The new blocking behavior adds a third state between the two previous states mentioned, considering then 3 states:

1. As long as there are no writes to the table in the current transaction and no LockTable calls on the table records, all reads will be accompanied by the READUNCOMMITTED hint. This is the default value for all reads in Business Central and the only level of transaction isolation that allows dirty reads.
2. The READCOMMITTED hint will be added to subsequent reads if writes have been made to the table in the current transaction. It allows multiple sessions to simultaneously read and write to the same table, as long as their modifications do not clash with each other, because it locks the data with a shared lock (S).
3. The UPDLOCK hint will be applied to subsequent reads if LockTable has been called on a record in this table. Conflicts may arise with other users if they try to view or modify the same table in the current transaction until you commit or revert the changes because it locks the data with an exclusive lock (X).

Undoubtedly, waiting for locks occupies a large part of the processing time, so this new proposed behavior is undoubtedly a very important improvement..

// locking behaviour with tri-state locking
trigger OnAction()
var
    currency1: Record Currency;
    currency2: Record Currency;    
begin
    currency1.FindFirst(); // SQL statement use READUNCOMMITTED

    currency1.Code := 'DKK';
    currency1."ISO Code" := 'DKK';
    currency1.Symbol := 'Kr';
    currency1.Insert();

    currency2.FindLast(); // SQL statement use READCOMMITTED (so locks data with a shared lock)
end;

Enabling

• Saas: You do not need to do anything to enable this enhancement in new environments generated in version 23.0 and later; version 23.0 will enable it by default. You can enable and disable the functionality through the features management page. Users will see the changes the next time they log in to Business Central.
• OnPremise: The EnableTriStateLocking parameter in the server configuration must also be set to true to enable this type of locking. Business Central Server Instance Settings

Recommendations

It is very likely that some of your extensions will need to be adjusted to implement the new blocking behavior.

Therefore, it is advised that you test your extensions beforehand. To do this, copy the production environment into a sandbox, enable the functionality, test, review and make the necessary code adjustments.

Then safely enable it in production and improve the performance of your transactions.

---

This results in fewer errors and interruptions due to blocking-related problems, making Business Central faster and easier to use.

Those with large or complex data sets or those who run frequent and intensive operations on their online services will especially benefit from this enhancement.

I hope this information helps you.

---

Más información / More information

• Tri-state locking
• Dynamics 365 Business Central 2023 Wave 2 release: measuring the impact of the new data structure
• Transaction isolation in Business Central
• Table hints (Transact-SQL)