The main reasons for switching to managed locks are:

• The main reason is the recommendation of 1C: Expert based on indications or 1C: MCC
• Problems with concurrent user work ()
• Using Oracle, PostgreSQL and.

Cost of work:

The essence of managed locks

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

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

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

After the configuration is switched to controlled mode, the platform activates additional functionality"Lock manager" and control over data integrity is now carried out not on the side of the DBMS, but on the side of the 1C server. This increases the load on the 1C server hardware (faster processors and more memory are needed), and actually introduces even a slight slowdown (a few percent), however, it improves the situation with locks much more significantly (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 parallelism.

New configurations of 1C company are implemented immediately in a controlled mode.

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

Answer: It is possible, the audit will serve as an additional justification for the advisability of transferring to managed locks, as well as assess the contribution of automatic locks to the overall slowdown and whether additional efforts are needed besides the transfer.

• Question: To transfer to UB, what kind of access do you need to provide - RDP, TeamViewer? Or can I send you a configuration file?

Answer: We try not to limit ourselves to one specific technology. remote access, fits any remote access technology... If it doesn't matter to you, then RDP is more practical.
We can perform optimization 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, then we can test it thoroughly before we send you the result of the work.

• Question: We have 10 full-time programmers who change something in the config every day. Shared configuration storage is used. " How will the interaction be organized when transferring to UB? Or should all programmers go on vacation?

Answer: As a rule, our changes are made within a couple of days. The rest of the time is spent on testing the changes made, including from the point of view of the required logic determined by the business and not by technical considerations. We we can make changes to separate file configuration cf, and then your programmer will add it to the repository. You don't have to send anyone on vacation... In other options for interaction, you just need to agree on which objects your developers plan to seize, so that we 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 "wheel" for a day.

Mechanism transactional locks used for concurrent user access to the DBMS.
A transaction is a kind of indissoluble operation during which the state of the base changes. This is the minimum quantum of changes: you cannot make a half-transaction; if the transaction is not completed, the database will be rolled back to its initial state.
Since a transaction captures an array of data, a nuance arises regarding access to this array: for example, one transaction changes data, while another tries to read it. The reading result may be incorrect, because will not turn on recent changes... Therefore, transaction isolation works at the DBMS level. The following isolation levels are possible:

• Read uncommited- while one transaction changes the array, another cannot change it, but can read. Lowest isolation level.
• Read commited- while one transaction changes the array, the other can neither change nor read it
• Repeatable read- while one transaction reads an array, another cannot change it, but can read
• Serialaizable- while one transaction reads the array, the other can neither change nor read it. All operations are sequential. Maximum isolation level.

If the 1C: Enterprise configuration is set automatic blocking mode, then the transaction isolation level is selected by the DBMS. In the case of MS SQL, it 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 the appearance of locks 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 MS SQL transaction isolation level will be Read commited. The platform itself will isolate the data without relying on the DBMS.

Enabling the managed blocking mode occurs in the configuration properties:

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

If the configuration as a whole is set Auto mode locks, then all transactions in 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 managed. If the configuration is set to Automatic and Controlled, then the mode for each object will be determined by its settings.

There is one point for Automatic and Controlled modes. A single transaction for the user can represent several transactions from the point of view of the platform. For example, interactively navigating a document across the register makes two transactions are a record of the document itself, and within this transaction is a record of a set of rows by register. Depending on the control mode of locks for the document itself and the register moved by it, four situations are possible:

1. Document mode Automatic, register mode Automatic ->
2. Document mode Managed, register mode Managed -> write by register in controlled mode
3. Document mode Automatic, register mode Guided -> write by register in automatic mode
4. Document mode Managed, register mode Automatic -> exception (error)

Question 06.59 of exam 1C: Professional on the platform. When posting a document to a register, if the document has an automatic transactional locks management mode, and the register has a controlled one (in the configuration properties, the "Automatic and managed" option is used), then such a posting will result in:

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

Question 06.60 of exam 1C: Professional on the platform. When posting a document to a register, if the document has a managed transactional locks management mode, and the register has automatic (the "Automatic and managed" option is used in the configuration properties), then such posting will result in:

1. to the occurrence of an error situation
2. the whole transaction will be performed automatically
3. the whole transaction will be executed in a controlled manner

The first correct answer is determined by the first transaction, if controlled, then an error.

Question 06.61 of exam 1C: Professional on the platform. When posting a document to a register, if the document has an automatic transactional locks management mode, and the register has a managed one (the "Controlled" option is used in the configuration properties), then such a posting will result in:

1. to the occurrence of an error situation
2. the whole transaction will be performed automatically
3. the whole transaction will be executed in a controlled manner

Data Lock Management Mechanism in a transaction, it allows blocking of mutable data not by means of the used database management system, but by means of the platform. Such data lock management is performed not in terms of the DBMS data, but in terms of the domain. This allows more precise locks to be imposed and increased user concurrency.

Configuration 1C: Enterprise 8 can operate in one of three modes of 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 provide a consistent and consistent reading of data, and no additional action is required from the developer to manage the locks.

Controlled mode allows to increase the parallelism of users in the client-server mode of work due to the use of a lower level of isolation of database transactions (Read Committed). When writing data to a transaction, embedded language objects automatically lock the required data. A developer needs to manage data locks when business logic requires consistent and consistent reading of data in a transaction.

Automatic and controlled the mode allows 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, with several of the most heavily used documents), or to gradually transfer large configurations to transaction lock management mode.

In a summary form, the differences between automatic interlocks and controlled interlocks are shown in the following table:

Most often, the need to manage data locks in a transaction arises in the process of posting documents, when you need to read and then write the changed data to the same tables. For example, if the balance is checked during document posting.

Especially for this, the record sets of accumulation registers and accounting registers have a 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 Movement.

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

Below is an example of "manual" control of data locks when reading accumulation register data. AccountingNomenclature in processing document posting Sales Invoice... In this example, managed locks are created and set entirely by means of the embedded language.

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 the locks in a transaction in order to do so. These rules are provided by the 1C: Enterprise platform through the use of certain transaction isolation levels in a particular DBMS. This mode of operation is the easiest for the developer, but in some cases (for example, with intensive simultaneous work a large number users), the used transaction isolation level in the DBMS cannot provide sufficient parallelism, which manifests itself in the form of a large number of lock conflicts when users work.

When operating in the mode of controlled locks, the 1C: Enterprise system uses much more low level isolation of transactions in the DBMS, which can significantly increase the parallelism of the users of the applied solution. However, unlike the automatic blocking mode, this level isolation of transactions can no longer by itself enforce all the rules for working with data in a transaction. Therefore, when working in a controlled mode, the developer is required to independently manage the locks set in the transaction.

In a summary form, the differences between automatic interlocks and controlled interlocks are shown in the following table:

Setting the blocking mode in the configuration

The configuration has the property Data Lock Control Mode. 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 (default for a new configuration), and Automatic and Managed. The Automatic and Controlled 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 value Automatic and controlled means that for a specific configuration object the mode specified in its Data lock control mode property: Automatic or Controlled will be used.
It should be noted that the data locking control mode specified for the 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, an object write operation 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
the StartTransaction () method, not the value of the property of the metadata object Data Lock Control Mode.
By default, the Lock Mode is set to DataLock Management Mode. Automatic, so the
in order to use the managed locking mode in an explicit transaction, you must specify the value of this parameter
DataLock Management Mode.

Working with managed locks using the embedded language

To manage locks in a transaction, the DataLock built-in language object is used. This object can be instantiated using the 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), the locks are acquired and will be released automatically at the end of the transaction. If the Lock () method is executed outside of a transaction, then no locks will be acquired.

Conditions are set on the equality of the field value to the specified value or on the occurrence of the field value in the specified range.
Conditions can be set in two ways:

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

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

• shared,
• exceptional.

The managed lock compatibility table looks like this

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

Features of work in the "Automatic and controlled" mode

When operating in the automatic and controlled interlock control mode, there are two points to consider:

Regardless of the mode specified for a given transaction, the system will set the appropriate controlled
blocking.
The lock management mode is determined by the highest-level transaction. In other words, if another transaction was started by the time the transaction began, then the transaction being started can be performed only in the mode that is set for an 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 set the corresponding managed locks when writing data in this transaction. This implies that transactions executing in managed lock mode may conflict with transactions executing in automatic lock management mode.

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

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