Data lock management mechanism in a transaction allows locking 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 DBMS data, but in terms of the subject area. Due to this, the locks are applied "more accurately" and the parallelism of the work of users is increased.
The 1C:Enterprise 8 configuration can work 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 read of the data, and no additional action is required from the developer to manage locks.
Managed mode allows you to increase the parallelism of the work of users in the client-server mode of operation by using a lower level of database transaction isolation (Read Committed). When writing data in a transaction, 1C:Enterprise objects automatically lock the required data. The developer needs to manage data locks in cases where business logic requires a consistent and consistent reading of data in a transaction.
Automatic and controlled the mode allows using the ability to manage locks in a transaction only for some configuration objects. This mode can be used to optimize the concurrency of user work with individual application objects (for example, with several of the most intensively used documents) or to gradually transfer large configurations to the mode of managing locks in a transaction.
In a summary form, the differences between working in the automatic blocking mode and in the managed 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 check balances when posting a document.
Especially for this, the record sets of accumulation registers and accounting registers have a property BlockToChange.
If you need to control the balances, and then record movements in the same register, then this property must be set for the recordset of this register in the property movements.
The effect of this property is the same as if the developer had independently set (written in the code) the necessary 1C:Enterprise 8 managed locks. The platform will set the required managed lock automatically when writing this set of records. As a result, other managed transactions using a similar lock cannot start reading this register until the current transaction ends.
Below is an example of "manual" control of data locks when reading the data of the accumulation register AccountingNomenclature in the processing of posting a document Sales Invoice. In this example, managed locks are created and set entirely using the 1C:Enterprise 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 managed locks in a transaction.
The fundamental difference between these modes is as follows. The automatic locking mode does not require the developer to do anything to manage locks in a transaction in order to do so. These rules are provided by the 1C:Enterprise system platform through the use of certain levels isolation of transactions in one or another DBMS. This mode of operation is the simplest for the developer, however, in some cases (for example, when a large number of users work intensively at the same time), 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 during user work.
When operating in the managed blocking mode, the 1C:Enterprise system uses much more low level isolation of transactions in the DBMS, which can significantly increase the parallelism of the work of users of the application solution. However, unlike the automatic blocking mode, this level of transaction isolation can no longer by itself ensure that all the rules for working with data in a transaction are fulfilled. Therefore, when working in managed mode, the developer is required to independently manage the locks acquired in the transaction.
In a summary form, the differences between working in the automatic blocking mode and in the managed blocking mode are shown in the following table:
Setting the lock 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 (set by default for a new configuration), and Automatic and Managed. The values Automatic and Managed mean that the appropriate blocking mode will be used for all objects in the configuration, regardless of the values set for each of the objects. The value Automatic and Managed means that the mode specified in its Data Lock Management Mode property will be used for a specific configuration object: Automatic or Managed.
It should be noted that the data lock management mode specified for a metadata object is set for those transactions that are initiated by 1C:Enterprise when working with this object's data (for example, when modifying the object's 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 lock management mode will be determined by the value of the Lock mode parameter
method StartTransaction(), and not the value of the property of the metadata object Data lock control mode.
By default, the Lock Mode parameter is set to DataLockControlControlMode.Automatic, so for
In order to use the managed locking mode in an explicit transaction, you must specify the value of this parameter
DataLockControlMode.Managed.
Working with managed locks using the 1C:Enterprise language
To manage locks in a transaction, the LockData object of the built-in language is used. An instance of this object can be created using the constructor and allows you to describe the necessary 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 when the transaction ends. If the Lock() method is executed outside of a transaction, no locks will be set.
Conditions are set for equality of the field value 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 DataLockItem object);
- by specifying the data source containing the required values (the DataSource property of the DataLockItem object).
Each blocking element can be assigned one of two blocking modes:
- shared,
- exceptional.
The managed lock compatibility table looks like this
Shared locking means that locked data cannot be changed by another transaction until the end of the current transaction.
The exclusive lock mode means that the locked data cannot be changed by another transaction until the end of the current transaction, and also cannot be read by another transaction that establishes a shared lock on this data.
Features of work in the "Automatic and controlled" mode
There are two things to keep in mind when operating in the Lock Control Mode Automatic and Managed:
Regardless of the mode specified for a given transaction, the system will set the appropriate managed
blocking.
The lock management mode is determined by the transaction of the "upper" level. In other words, if another transaction was started by the time the transaction started, then the transaction being started can be executed only in the mode that is set for the already executing transaction.
Let's consider these features in more detail.
The first feature is that even if automatic lock management mode is used for a transaction, the system will additionally set the appropriate managed locks when writing data in this transaction. It follows from this that transactions executing in controlled lock mode may conflict with transactions executing in lock mode. automatic control locks.
The second feature is that the lock management mode specified for the metadata object in the configuration or explicitly specified at the beginning of the transaction (as a parameter of the StartTransaction() method) is only a “desired” mode. The actual lock management mode in which a transaction will be executed depends on whether the given call started the transaction first, or by this moment another transaction has already started in the current 1C:Enterprise session.
For example, if you want to manage locks when writing ledger recordsets when you post a document, then managed locking mode must be set for both the ledger itself and the document, since the writing of ledger recordsets will be performed in the transaction opened when the document is written.
The main reasons for switching to managed locks are:
- The main reason is the recommendation of 1C: Expert based on the testimony or 1C: TsUP
- Problems with parallel work of users ()
- Using Oracle, PostgreSQL and .
Cost of work:
The essence of managed locks
When working in automatic lock management mode, 1C:Enterprise sets a high degree of data isolation in a transaction at the DBMS level. This makes it possible to completely eliminate the possibility of obtaining non-integral or incorrect data without any special efforts on the part of application developers.
It's comfortable and the right approach with a small number of active users. The price of ease of development is a certain amount of redundant locks at the DBMS level. These locks are related both to the peculiarities of the implementation of locking mechanisms in the DBMS itself, and to 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 lock redundancy becomes noticeable in terms of performance in parallel mode.
After the configuration is transferred to the 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 hardware of the 1C server (you need faster processors and more memory), and actually introduces even a slight slowdown (a few percent), but it improves the situation with locks much more significantly (fewer locks due to locks on the object, and not on a combination of tables, less lock area and, in some cases, less lock lifetime by reading, i.e. not until the end of the transaction). This improves overall parallelism.
New configurations of the 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 expediency of switching to managed locks, as well as to 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 should be provided - RDP, TeamViewer? Or can you send me the config file?
Answer: We try not to limit ourselves to one specific technology remote access, good any remote access technology. If it doesn't matter to you, then RDP is more practical.
We can optimize according to 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 base, then we can thoroughly test before we send you the result of the work.
- Question: We have 10 full-time programmers who change something in the conference every day. used shared storage configuration". How will interaction be organized during the transfer to UB? 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 falls on testing the changes made, including in terms of the required logic determined by business and not technical considerations. We we can make changes to a separate configuration file cf , and then your programmer will check in the repository. You don't have to send anyone on vacation.. In other interaction options, 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 a day.
