Error using lock manager. Transaction Data Lock Control, Mechanism. Working with managed locks using the built-in language

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 (a 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 transferring to managed locks and also to assess 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.

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

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 DBMS data, but in terms of the domain. 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 parallelism of user work in the client-server mode of operation by using a lower level of database transaction isolation (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 posting documents, 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 Sales Invoice. In this example, managed locks are created and set entirely using the built-in language.