Documentation:IsolationLevel

IsolationLevel

This page was created by Hans.karlsen on 2022-04-24. Last edited by Wikiadmin on 2026-07-29.

You can configure how strongly SQL database reads and updates are isolated from concurrent work by setting the fetch and update isolation levels in SqlDatabaseConfig; this page is for developers maintaining MDriven applications with SQL persistence.

What isolation level means

An isolation level is a database transaction setting that controls how much one database task is isolated from other tasks running at the same time. The database uses it to determine which concurrent changes a task can observe and how concurrent operations interact.

MDriven uses separate settings because reading data and updating data have different concurrency requirements:

Setting	Used for	Why it matters
`FetchIsolationLevel`	Reading (fetching) data from the SQL database.	Controls the isolation used while MDriven retrieves data.
`UpdateIsolationLevel`	Updating data in the SQL database.	Controls the isolation used while MDriven performs updates.

For the database definition of the available isolation-level values and their behavior, see the .NET IsolationLevel documentation.

Configure the levels

Open the application's SqlDatabaseConfig.
Set FetchIsolationLevel to the isolation level to use when MDriven fetches data.
Set UpdateIsolationLevel to the isolation level to use when MDriven updates data.
Test the configuration with concurrent users and processes that read and update the same data.

Treat the two values as separate decisions. A level suitable for fetching data is not automatically suitable for updates.

Protect update integrity

Do not set UpdateIsolationLevel too low. During an update, MDriven extracts new IDs and timestamps. With insufficient isolation, concurrent tasks may not obtain unique values. This can cause data-integrity problems.

For example, consider two users saving new objects at nearly the same time. If the update isolation is too low, the operations can interfere with extraction of the new IDs or timestamps. The result may be values that are not unique when they must be unique. Validate update behavior under realistic concurrent load before deploying a changed setting.

Scope and related persistence settings

This setting applies to persistence in an SQL database. For the wider persistence-mapping context, including the scope of SQL persistence and MDrivenServer defaults, see Documentation:Working with Code and Persistence Mapping.

Isolation level is a transaction-concurrency concern; it is unrelated to attribute precision, scale, and length settings.

Validation and read-only slave consistency

This page describes documented consistency-related behavior in MDriven: validation of entered data and the behavior of read-only slave servers.

Validate business data

MDriven validation is intended to ensure that entered data is correct, consistent, and conforms to application business rules before it is processed or persisted.

Validation rules use Object Constraint Language (OCL). They can be defined at class or attribute level and can also provide feedback in the user interface while a user enters data.

Common documented validation types include:

Required fields.
Data-type validation through the selected model attribute type.
Range validation.
Format validation, including regular expressions.
Conditional validation.

For example, a model can require information needed by a business process before that information is accepted. Create a validation rule with a rule name, OCL expression, and message, then apply the rule to the relevant ViewModel column. The client provides feedback when a validation rule is violated.

Read-only slave servers

In the documented master/slave setup, a read-only slave server is connected to a master server. A save directed to a read-only slave is routed to the master.

The master is the server that acts on data and runs server-side jobs. Slave servers can improve read access, while writes remain dependent on the master. Changes written at the master are stored in a database transaction log; slave servers frequently check for changes and can obtain updates through the replication chain.

Replication can introduce delay. The source describes typical save delay as usually less than one second in the discussed scenario, but this is not a guaranteed latency. Do not assume that a newly written value is immediately available from every read-only slave.

Scope of this page

The supplied documentation does not define MDriven isolation-level settings or their values. It also does not document explicit transaction commands, locking behavior, conflict handling, retry behavior, or database-specific recovery procedures. These topics require confirmation from authoritative MDriven and database-provider documentation before they are used as operational guidance.

Contents