Self-esteem and self-love 

Controlled locking mechanism. Managing data locks in a transaction, mechanism (Transaction Data Lock Control, Mechanism) Working with managed locks using the built-in language

Data lock management mechanism in a transaction allows you to lock changeable data not by means of the database management system used, but by means of the platform. Such data lock management is performed not in terms of the DBMS data, but in terms of the subject area. Thanks to this, locks are applied more accurately and user concurrency increases.

Configuration 1C:Enterprise 8 can operate in one of three modes for managing locks in a transaction:

  • auto;
  • managed - standard mode for new configurations;
  • automatic and controlled.

IN automatic mode Data lock management uses the repeatable read and serializable transaction isolation levels provided by the database management system. These transaction isolation levels ensure consistent and consistent reading of data without requiring any additional lock management efforts from the developer.

Managed mode allows you to increase the concurrency of users in the client-server mode of operation by using a lower level of isolation of database transactions (Read Committed). When writing data to a transaction, built-in language objects automatically lock the required data. The developer needs to manage data locks in cases where business logic requires consistent and consistent reading of data in a transaction.

Automatic and controlled mode allows you to use the ability to manage locks in a transaction only for some configuration objects. This mode can be used to optimize user concurrency with individual application objects (for example, a few of the most intensively used documents) or to gradually transition large configurations to transaction lock management mode.

In summary, the differences when working in automatic blocking mode and in controlled blocking mode are shown in the following table:

Most often, the need to manage data locks in a transaction arises in the process of document posting, when you need to read and then write changed data to the same tables. For example, if you are monitoring balances when posting a document.

Especially for this purpose, sets of records of accumulation registers and accounting registers have the property BlockForChange.

If you need to control the balances and then record movements in the same register, then this property must be set for the set of records of this register in the property Movements.

The effect of this property is the same as if the developer independently installed (prescribed in code) the necessary managed locks for 1C:Enterprise 8. The platform will install the necessary managed lock automatically when writing this set of records. As a result, other managed transactions using the same lock will not be able to start reading this register until the current transaction has completed.

Below is an example of "manual" control of data locks when reading accumulation register data Accounting for items in document processing Consumable invoice. In this example, managed locks are created and set entirely using the built-in language.

Mechanism transaction locks used for competitive user access to the DBMS.
A transaction is a kind of continuous operation during which the state of the database changes. This is the minimum quantum of change: you cannot make half a transaction; if the transaction does not complete, the database will be rolled back to its initial state.
Since a transaction captures an array of data, a nuance arises in accessing this array: for example, one transaction changes the data, and another tries to read it. The reading result may be incorrect, because will not include the latest changes. Therefore, transaction isolation works at the DBMS level. The following isolation levels are possible:

  • Read uncommitted- while one transaction changes the array, another cannot change it, but can read it. Lowest level of insulation.
  • Read committed- while one transaction changes the array, another cannot change or read it
  • Repeatable read- while one transaction reads the array, another cannot change it, but can read it
  • Serializable- while one transaction reads the array, another cannot change or read it. All operations are sequential. Maximum insulation level.

If the 1C:Enterprise configuration is set to automatic locking mode, then the transaction isolation level is selected by the DBMS. In the case of MS SQL, this will be Repeatable read or Serializable levels, that is, data isolation is close to maximum. This solves problems with data correctness, but can lead to blocking at the DBMS level during intensive user work. Therefore, 1C:Enterprise has its own functionality for working with locks, which is activated by enabling the managed locks mode. In this case, the transaction isolation level for MS SQL will be Read committed. The platform itself will isolate the data without relying on the DBMS.

Managed locking mode is enabled in the configuration properties:

Also, the locking mode can be set for specific configuration objects:

If the configuration as a whole is set to Automatic locking mode, then all transactions for all registers will work in automatic mode, regardless of the mode that is set for the configuration object. If Managed, then similarly, all transactions will be in Managed. If the configuration mode is set to Automatic and controlled, then the mode for each object will be determined by its settings.

There is one point for the Automatic and controlled mode. A single transaction for a user may represent several transactions from the platform’s point of view. For example, interactively posting a document to a register makes two transactions - a record of the document itself, and within this transaction a record of a set of rows by register. Depending on the lock management mode for the document itself and the register it moves, four situations are possible:

  1. Document mode Automatic, register mode Automatic ->
  2. Document mode Managed, register mode Managed -> record by register in managed mode
  3. Document mode Automatic, register mode Controlled -> record by register in automatic mode
  4. Document mode Managed, register mode Automatic -> exception (error)

Question 06.59 of exam 1C: Platform Professional. When posting a document through any register, if the document has an automatic transaction lock management mode and the register has a managed mode (the “Automatic and managed” option is used in the configuration properties), then such posting will lead to:

The correct answer is the second one, we determine it by the first transaction, if it is automatic, then everything is automatic.

Question 06.60 of exam 1C: Platform Professional. When posting a document through any register, if the document has a managed mode for managing transaction locks, and the register has an automatic one (in the configuration properties the “Automatic and managed” option is used), then such posting will lead to:

  1. to an error situation
  2. the entire transaction will be completed automatically
  3. the entire transaction will be completed in a controlled manner

The correct answer is the first, we determine by the first transaction, if it is controlled, then it is an error.

Question 06.61 of exam 1C: Platform Professional. When posting a document through any register, if the document has an automatic mode for managing transaction locks, and the register has a managed mode (the “Managed” option is used in the configuration properties), then such posting will lead to:

  1. to an error situation
  2. the entire transaction will be completed automatically
  3. the entire transaction will be completed in a controlled manner

The main reasons for switching to managed locks:

  • The main reason is the recommendation of 1C:Expert based on testimony or 1C:TsUP
  • Problems with concurrent users ()
  • Using Oracle, PostgreSQL and .

Cost of work:

The essence of managed locks

When working in automatic locking control mode, 1C:Enterprise sets a high degree of data isolation in a transaction at the DBMS level. This allows you to completely eliminate the possibility of obtaining incomplete or incorrect data without any special efforts on the part of application developers.

This is a convenient and correct approach for a small number of active users. The price of ease of development is a certain amount of redundant locking at the DBMS level. These locks are associated both with the peculiarities of the implementation of locking mechanisms in the DBMS itself, and with the fact that the DBMS cannot (and does not) take into account the physical meaning and structure of 1C:Enterprise metadata objects.

When working with high contention for resources (large number of users), at some point the impact of redundant locks becomes noticeable in terms of performance in parallel mode.

After transferring the configuration to managed mode, the additional functionality of the “lock manager” is activated in the platform and data integrity control is now carried out not on the DBMS side, but on the 1C server side. This increases the load on the 1C server hardware (faster processors and more memory are needed), and actually introduces even a slight slowdown (several percent), but it significantly improves the situation with locks (fewer locks due to locks on an object, and not on a combination of tables, less blocking area and in some cases the lifetime of read locks is shorter, i.e. not until the end of the transaction). This improves overall concurrency.


New configurations from 1C were implemented immediately in a controlled mode.

  • Question: Is it possible to do an audit first and then transfer to FM?

Answer: Yes, the audit will serve as an additional justification for the feasibility of switching to managed locks and also to evaluate the contribution of automatic locks to the overall slowdown and whether additional efforts are needed besides the transfer.

  • Question: To transfer to UX, what kind of access should be provided - RDP, TeamViewer? Or can I send you the configuration file?

Answer: We try not to limit ourselves to one specific remote access technology, it will do any remote access technology. If it doesn't matter to you, then RDP is more practical.
We can perform optimization based on the sent configuration file, but then we will not be able to debug some real data and you will have to test more carefully. If we perform optimization on a copy of the database, we can test it more thoroughly before we give you the result of the work.

  • Question: We have 10 full-time programmers who change something in the conference every day. A shared configuration store is used." How will interaction be organized during the transfer to UX? Or should all programmers be sent on vacation?

Answer: As a rule, our changes are made within a couple of days. The rest of the time is spent testing the changes made, including from the point of view of the required logic determined by business and not by technical considerations. We we can make changes to a separate configuration file cf , and then your programmer will commit it to the repository. No one will have to go on vacation. In other options for interaction, you just need to agree on which objects your developers plan to capture, so that we can build a work plan that is convenient for both parties. As a rule, your developers do not need to capture the entire configuration, or give us the “steering wheel” for the day.

The 1C:Enterprise system allows you to use two modes of working with the database: the mode of automatic locks in a transaction and the mode of controlled locks in a transaction.

The fundamental difference between these modes is as follows. The automatic locking mode does not require the developer to take any action to manage locks in a transaction. These rules are ensured by the 1C:Enterprise system platform through the use of certain levels of transaction isolation in a particular DBMS. This mode of operation is the simplest for the developer, however, in some cases (for example, with intensive simultaneous work of a large number of users), the transaction isolation level used in the DBMS cannot provide sufficient parallelism, which manifests itself in the form of a large number of locking conflicts when users work.

When operating in managed locking mode, the 1C:Enterprise system uses a much lower level of transaction isolation in the DBMS, which can significantly increase the concurrency of users of the application solution. However, unlike the automatic locking mode, this level of transaction isolation can no longer by itself ensure compliance with all rules for working with data in a transaction. Therefore, when working in managed mode, the developer is required to independently manage the locks set in the transaction.

In summary, the differences when working in automatic blocking mode and in controlled blocking mode are shown in the following table:

Setting the blocking mode in the configuration

The configuration has the Data Lock Control Mode property. Each application configuration object also has a Data Lock Control Mode property.
The data lock control mode for the entire configuration can be set to Automatic, Managed (the default for a new configuration), or Automatic and Managed. The Automatic and Managed values ​​mean that the corresponding blocking mode will be used for all configuration objects, regardless of the values ​​​​set for each of the objects. The Automatic and Managed value means that for a particular configuration object the mode specified in its Data Lock Control Mode property will be used: Automatic or Managed.
It should be noted that the data locking control mode specified for a metadata object is set for those transactions that are initiated by the 1C:Enterprise system when working with the data of this object (for example, when modifying the object data).
If, for example, the operation of writing an object is performed in a transaction initiated by the developer (the StartTransaction() method), then the data locking control mode will be determined by the value of the Locking Mode parameter
method StartTransaction(), and not the value of the Data Lock Control Mode metadata object property.
By default, the Blocking Mode parameter is set to Data Blocking Control Mode. Automatic, so for
In order to use managed locking mode in an explicit transaction, you must specify the value of this parameter
Data Lock Control Mode. Managed.

Working with managed locks using the built-in language

To manage locks in a transaction, the built-in language object DataLock is used. An instance of this object can be created using a constructor and allows you to describe the required lock spaces and lock modes. To set all created locks, use the Lock() method of the DataLock object. If this method is executed in a transaction (explicit or implicit), locks are acquired and will be released automatically when the transaction ends. If the Lock() method is executed outside of a transaction, no locks will be acquired.

Conditions are set for the field value to be equal to the specified value or for the field value to be within the specified range.
Conditions can be set in two ways:

  • by explicitly specifying the field name and value (SetValue() method of the DataLockElement object);
  • by specifying a data source containing the required values ​​(DataSource property of the DataBlockingElement object).

For each blocking element, one of two blocking modes can be set:

  • shared,
  • exceptional.

The managed locking compatibility table looks like this:

Shared locking mode means that locked data cannot be modified by another transaction until the end of the current transaction.
Exclusive locking means that locked data cannot be modified by another transaction until the end of the current transaction, nor can it be read by another transaction that holds a shared lock on the data.

Features of operation in the “Automatic and controlled” mode

When working in Automatic and Controlled blocking control mode, two features should be taken into account:

Regardless of the mode specified for a given transaction, the system will install the appropriate managed
blocking.
The lock control mode is determined by the highest-level transaction. In other words, if another transaction was started at the time the transaction started, then the started transaction can only be executed in the mode that is set for the already running transaction.

Let's consider the listed features in more detail.

The first feature is that even if the automatic lock management mode is used for a transaction, the system will additionally install corresponding managed locks when writing data in this transaction. It follows that transactions executed in managed locking mode may conflict with transactions executed in automatic locking management mode.

The second feature is that the lock management mode specified for a metadata object in the configuration or specified explicitly when starting a transaction (as a parameter to the StartTransaction() method) is only a “desired” mode. The actual lock management mode in which the transaction will be executed depends on whether this is the first call to start a transaction, or whether another transaction has already started in this session of the 1C:Enterprise system at that moment.

For example, if you need to manage locks when writing sets of register records when posting a document, then the managed locking mode must be set both for the register itself and for the document, since writing sets of register records will be performed in the transaction opened when writing the document.