How to fix 1s 8.3 lock conflict. How I diagnosed blocking problems. A large number of operations performed

It is not uncommon when working in 1C to receive the error “Lock conflict when executing transactions: The maximum waiting time for granting a lock has been exceeded.” Its essence lies in the fact that several sessions are trying to simultaneously perform similar actions, affecting the same resource. Today we will figure out how to fix this error.

A large number of operations performed

The first step when looking for reasons is to clarify how many concurrent users are in the information base in which such an error is generated. As we know, their maximum number can be quite large. This is both a thousand and five thousand.

The mechanism of locking and transactions is described in the developer's guide. They are used when multiple sessions access the same data simultaneously. It is logical that the same data cannot be changed by different users at the same time.

You should also check whether any of the users have started processing by massive change data. This could be like, month end and the like. In this case, after the processing is completed, the error will disappear on its own.

Scheduled tasks

It is not uncommon for the cause of an error to lie in a system that processes large amounts of data. It is recommended to do such things at night. Set a schedule for performing such routine tasks outside of work hours.

In this way, users will work in a stable system, and the routine tasks themselves will be completed successfully, since the likelihood of conflicts with user sessions will be reduced.

"Hung sessions"

The problem of “stuck sessions” of users is familiar to almost everyone who has encountered 1C service. The user could have left the program a long time ago, or closed a document, but his session still remains in the system. The problem is most often isolated and it is enough to end such a session through the administrator console. The same problems can arise with background jobs.

According to numerous comments on the Internet, such situations are more common when using network security keys. If the situation with “freezing sessions” is repeated systematically, this is a reason to thoroughly check and maintain the system and servers (if the database is client-server).

Errors when writing configuration

All standard configurations are developed by qualified specialists and experts. Each system is thoroughly tested and optimized for faster and more correct operation.

In this regard, the cause of the error may lie in suboptimal code written by a third-party developer. This could be a "heavy" request that will block data for a long period of time. There are also frequent cases of constructing algorithms with low performance and violation of logic.

There is a high probability that the locking conflict arose precisely because of developer errors if it arose after a program update. To check, you can simply “roll back” the improvements, or refactor the code.

What are locks in 1C, why are they needed and how to avoid problems when working with them

Surely many of you when using information systems 1C Enterprise (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) encountered such a phenomenon as blocking. Moreover, as a rule, everyone calls this phenomenon differently: “1C blocking”, “1C blocking conflict”, “1C blocking errors”, “1C transaction blocking” and other names. Let's take a quick look at what locks (not deadlocks) are, why they are needed, and how to avoid problems when working with them.

Locks themselves (including in 1C and other systems) are a useful tool that provides the ability to consistently work with shared resources. For example, the concept of “shared resources” surrounds us throughout life, for example, while you are driving a car, no one else can drive it. Therefore, the car is a shared resource. And the second driver waits until you arrive, for example, your wife/husband. You both compete for a common resource - a car. Who will drive the car in current moment You define on a conceptual level, how should we be in automated systems??? This is why we came up with a tool blocking, which provide organization for the process of accessing a shared resource and define a queue. As a rule, in life, as in information systems (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), there are a lot of shared resources, so there are also a lot of blocking. Now the second one important point– how long will your wife/husband wait for your car to be released? It’s logical to assume that it won’t last forever. Therefore, locks are given a timeout limit - otherwise known as a timeout time. Timeout is the maximum time a competing participant (your wife/husband) waits for the shared resource to be freed. Then either he continues to wait for the same amount of time, or he walks. In 1C information systems, the expiration of the timeout ends with the message “1C lock conflict”, “1C lock errors”, “1C transaction locks”, “Timeout when locking”.

An important detail that should also be remembered is that locks (in particular in 1C) can be explicit (set by the user) and implicit (set by the SQL platform). In the article we are talking about explicit locks, so they are always used in a transaction, hence it turns out that “1C Blocking” and “1C Transaction Blocking” are synonyms.

We have decided that if the timeout is exceeded, the user will receive an error message; for him, the waiting process itself looks like the screen of the 1C information system is stuck. The likelihood of a timeout message appearing (1C user error) is affected by the following indicators:

• Many 1C locks in a transaction;
• Duration of the transaction.

To minimize messages associated with locking errors, it is necessary to either reduce the number of locks (optimize selectivity) or reduce the duration of transactions.
Now let’s determine how these indicators can be influenced in a real 1C information system.

To reduce a lot of blocking:

In 1C:Enterprise 7.7:

Information system 1C 7.7. For locking, table locks are used, which paralyze the work of users. As a rule, more than 50 people in one database cannot work without errors, and problems can also appear in databases of 20 users.
Solution:

• Flexible locks 1C from the Softpoint company. With their help, you will not only optimize many locks (replacing table locks with user locks), but also speed up selections, searches and reports.

In 1C:Enterprise 8.x:
Information system 1C 8.1., 1C 8.2., 1C 8.3. in automatic mode it uses redundant locks of the type (REPEATABLEREAD, SERIALIZABLE). This results in a degraded user experience of 100 or more.
Solution:

• Managed locks 1C - a built-in tool of the 1C platform for more selective configuration of locks. To use it, the programmer must write special operators in the right places in the code to block the necessary ones ( in his opinion!) records in information system tables;
• Flexible locks 1C - Softpoint technology for replacing standard locks with custom ones.

To reduce transaction times:

For any 1C information systems (1C 7.7., 1C 8.1, 1C 8.2, 1C 8.3) as for other information systems, similar approaches are used:

Check and correct setting routine database maintenance (file maintenance, indexes, statistics, temporary table database, Windows and SQLServer configuration);

Analysis and optimization of heavy 1C and SQL queries (index tuning, query rewriting);

Transaction redundancy check. In many cases, operations are unreasonably included in a transaction without realizing how this will affect the duration, and with it the performance.

1. If you want to independently deal with technical performance problems of 1C (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) and other information systems , then for you there is a unique list of technical articles in our Almanac (Blocking and deadlocks, heavy load on the CPU and disks, database maintenance and index tuning are just a small part of the technical materials that you will find there).
2. If you want to discuss performance issues with our expert or order a PerfExpert performance monitoring solution, then leave a request and we will contact you as soon as possible.

Hi all!

The other day at work I encountered a locking problem, namely, the message “There is a lock conflict while executing a transaction. The maximum waiting time for granting a lock has been exceeded.”

Obviously, there is no deadlock problem here, just some session put a lock and “forgot” to remove it. At the same time, the problem threatened with serious consequences - the document Sales of goods and services was not carried out. About 100 people work in the database at a time, and it is impossible to perform a typical and frequent operation!

There were two solutions - reboot the server or search for a failed session. The first solution is simple and quick, but, as someone already wrote here, you can reboot the server until you are fired. I decided to take the second path.

The first day - the problem appeared during the day; at first it seemed that the problem was with a remote user who had logged into the Configurator. It looked like the execution simply stopped at a point, and the blocking, of course, was not removed. After a couple of hours, we managed to release the configurator, but the problem did not go away. It was extremely undesirable to forcibly kill the configurator; perhaps they were working in it. After that, Google came into play. I found an article on this site that says how to find locks in an MS SQL DBMS, checked, there were no locks at the DBMS level. Strange. Next there were attempts to set up tech. magazine. Set it up, what next? In 15 minutes, a couple of gigs of logs! How to read them, what to look for? Unknown.

I found an article on how to see what is blocked using SQL Trace. Even if I find it, what next? I need a session!

Closer to 16:00, when I realized that I couldn’t wait any longer, I made a reboot. Hoping that this would not happen again (and this was the first time in six months of work), I breathed a sigh of relief, everything worked. But in vain... The second day - the same situation. I dug for an hour and a half, again incomprehensible attempts to google and so on. No results. Reboot. At the end of the day it happened again. Well, I think it’s great, I’ll calmly come home and sit and dig around. I come home, everything is fine. Sadly.

On the third day I watched the webinar, they talked about an interesting and effective way searching for a problem. I remembered, but the problem did not arise again. A week has passed and here it is - lockdowns again! I rub my hands and begin to act.

First, set up the journal. Yes, I can’t do without it, but now I know how to read it. We set two events: the first is TLOCK, the second is TTIMEOUT. The first displays all blocking events, the second shows blocking events that could not be installed within the allotted time. In fact, most likely just TTIMEOUT is enough.

We copy the technical log file to the designated place, fly into the program, call the lock, receive a message and remove or rename the technical log file. We don’t need tons of information about other blockings!

Go to the rphost_PID folder, find the text files and search for the word TTIMEOUT. We see the line:

53:16.789126-0,TTIMEOUT,5,process=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:computerName=ASUSM,t:connectID=17272,SessionID= 2242,Usr=*******,WaitConnections=8239

By the way, there can be several rphost_PID folders, it all depends on how many worker processes are running on the server.

And then everything is simple: look at the end of the line - WaitConnections = 8239, this is our CONNECTION number. We go to the server console, go to Connections, find this number and look at the session number. In my case, there were two sessions per user - the failed one and some other one. The session that the technical journal was pointing to crashed. And lo and behold! Everything worked, joy knows no bounds! But, as it turned out later, the session was not frozen :), they were working in it. Therefore, in the future, it is advisable to contact the user and warn.

In my opinion, a fairly standard solution to a fairly standard problem. It is not known why I didn’t come across it, perhaps because I had to look for it out of alarm, and when users didn’t press it, it wasn’t possible to carry out tests - there was no error.

When hundreds of users simultaneously work with programs and data, problems arise that are characteristic only of large-scale solutions. We are talking about problems caused by data blocking.

Sometimes users learn about blocking from messages indicating that they cannot write data or perform some other operation. Sometimes due to a very significant drop in program performance (for example, when the time required to perform an operation increases tens or hundreds of times).

Problems caused by blocking do not have general solution. Therefore, we will try to analyze the causes of such problems and systematize options for solving them.

REASONS FOR TRANSACTION BLOCKINGS

Let's first remember what locks are, and at the same time figure out whether they are necessary. Let's look at a couple of classic examples of blockages that we encounter in life.

Example 1: buying a plane or train ticket. Suppose we voiced our wishes to the cashier. The cashier tells us the availability of available seats, from which we can choose the one we like best (if there are several of them, of course). While we select and confirm our agreement with the proposed option, these seats cannot be sold to anyone else, i.e. are temporarily “blocked”. If they were not blocked, then by the time of confirmation there could be a situation where the tickets we selected had already been sold. And in this case, the selection cycle may have an unpredictable number of repetitions. While we are choosing places, they have already been sold!.. While we are choosing others, and they are no longer there...

Example 2: buying something in a store or at a bazaar. We approached the counter and chose the most beautiful apple from the hundreds available. They chose it and reached into their pockets for the money. What will it look like if, at that moment, while we are counting the money, the apple we chose will be sold to a buyer who came up later than us?

Thus, blocking in itself is a necessary and useful phenomenon. It is thanks to blocking that we guarantee that actions are completed in one step. And most often it’s not the most successful implementation that leads to negativity. software when, for example:

• an excessive number of objects (tickets, apples) are blocked;
• The blocking time is unreasonably extended.

EXCESSIVE BLOCKING IN TYPICAL 1C CONFIGURATIONS

On major projects, as a rule, we use 1C:Enterprise. That's why practical recommendations We will try to describe solutions to blocking problems using the example of the 1C:Enterprise + MS-SQL combination.

The 8th generation of 1C:Enterprise provides very, very good parallelism of use. Can work simultaneously with one configuration (that is, on one base) with normal servers and communication channels huge amount users. For example, hundreds of storekeepers process the issuance or receipt of goods, economists simultaneously calculate labor costs for various departments, accountants carry out calculations and payroll, etc.

But there is a reason why there is an opinion to the contrary - the myth that with intensive simultaneous use, working with solutions based on 1C:Enterprise is uncomfortable or impossible. After all, as soon as standard solutions for 1C:Enterprise begin to be used by hundreds of users on industrial scale, more and more often a window appears on the screen with a proud inscription: “Error when calling the context method (Write): Locking conflict when executing a transaction: ..." and then, depending on the type of SQL server used, something like “Microsoft OLE DB Provider for SQL Server: Lock request time out period exceeded. ...".

Almost all standard solutions in the proposed out-of-the-box implementation are configured for automatic lock management. “Automatic” here can be perceived as “paranoid”. Just in case, when processing any document, we block everything that may be somehow connected with it. So it turns out that when one user does something (and sometimes just writes it down), the rest can only wait.

I will express my opinion why 1C decided not to configure its standard solutions for high parallel use. The labor costs for such modification are not high - several “man months”, which is not significant on the scale of 1C. It seems to me that the reason is different.

Firstly, such a modification significantly complicates the processing of all documents. This means that for those consumers who use 1C for small tasks, without any gain there will be only a drawback - the difficulty of modifying the standard configuration will become more complicated. Statistics at the same time tell us which category of clients is the main feeder for 1C...

The second reason is buried in the typical basic settings of SQL servers, for example, MS-SQL, which is still used more often than others. It just so happens that priorities in the settings are given to saving RAM servers rather than reducing blocking. This leads to the fact that, if it is necessary to lock several rows, the SQL server makes a “memory- and processor-saving” decision - to lock the entire table at once!..

These are the shortcomings standard solutions or the specifics of the database server setup used are often identified with problems caused by locking. As a result, technical shortcomings lead to very significant organizational problems. After all, if an employee is given a reason to be distracted from work or to justify why the work could not be done, a minority will work effectively. Well, a message about blocking transactions or a “braking” program is an ideal justification for why something could not be done.

RECOMMENDATIONS FOR ELIMINATING EXCESSIVE BLOCKINGS FOR 1C:ENTERPRISE

What to do if solving the problems of excessive locking is so important?

At the final stage of implementation of all large complexes it is necessary to carry out fine-tuning to eliminate unnecessary transaction blocking. It is critical to resolve problems that may arise due to insufficiently developed blocking conditions or implementation techniques.

Because This operation is extremely important and must be performed constantly. Therefore, to simplify such modifications, we have developed a number of basic recommendations that we try to adhere to. Recommendations received and tested through the experience of a significant number of large-scale implementations.

1. If the DBMS or development system you are using (for example, 1C:Enterprise) uses automatic data locking mode by default, refuse automatic lock management. Configure blocking rules yourself, describe the criteria for blocking entire tables or individual rows.
2. When developing a program, whenever possible, access the tables in the same order.
3. Try not to write to the same table multiple times within the same transaction. If this is difficult, then at least minimize the time interval between the first and last write operation.
4. Analyze the possibility of disabling lock escalation at the SQL server level.
5. Clearly inform users about the reasons why they cannot perform any actions if they are due to blocking. Give accessible and understandable recommendations on what to do next.

If you look carefully at the recommendations, it becomes clear that such testing is appropriate not only for 1C:Enterprise, but for any systems. It doesn’t matter at all what language they are written in and what database server they work with. Most of the recommendations are universal in nature, and therefore are equally valid when using 1C:Enterprise and for “home-written” programs or other “boxed” ERP systems.

P.S. Did you know that we offer professional assistance with updating 1C software? best price?

Tags to search:

• Transaction locks
• Removing blockages
• 1C locks
• Lock
• Lock conflict
• Lock contention during transaction

In multi-user systems plays an important role proper organization structures and setting up locks. If it is not there, users will often have to deal with errors caused by competition for certain system resources. But there is a lock conflict problem that is familiar to many users. Why does a 1C lock conflict occur and how to resolve it?

Lock conflict in 1C 8.3 and its meaning

For most users, a message about a 1C lock conflict means only an error that prevents them from doing their work. They want to get rid of this problem as quickly as possible and besiege the IT department with complaints that “1C doesn’t work.”

But for system administrators and developers, such a message indicates that there may be problems in the configuration structure. Before you try to please users and remove blockages, you need to analyze the situation and understand the reason for the error message.

Reasons for blocking errors in 1C

Demonstrative load testing demonstrates that the 1C server can withstand the parallel operation of more than five thousand users. But ideal conditions for such experiments are unattainable in the everyday conditions of large and medium-sized companies. To achieve similar performance and error-free operation, the configuration must be ideally designed and tailored to the specific business processes of the enterprise.

If we do not take ideal options, then 1C locking conflicts occur for the following reasons:

Simultaneous work of users with a large amount of data. This root cause is dictated by the internal mechanisms of 1C. They involve prohibiting changes to data involved in a transaction launched on behalf of another user;

Errors and omissions in the configuration. The structure of standard solutions from the 1C company takes into account recommendations for maximizing productivity. But third-party developers do not always adhere to high standards, and the following flaws can often be found in their code:

• Suboptimal queries;
• Request for balances at the beginning of actions;
• Misunderstanding of the purpose of configuration objects and their incorrect use;
• Redundancy of interlocks built into the system or additionally developed.

How to fix a lock conflict in 1C 8.3

The system message “locking conflict when executing a 1C 8.3 transaction” does not characterize the configuration as incorrectly designed. But if such signals are ignored, then there is a possibility that at the most crucial moment, for example, when passing a quarterly or annual reports get into big trouble. At best, a sluggish system and dissatisfied users. At worst, the output data is incorrect, which may lead to penalties from regulatory authorities.

The solution to the problem of lock conflicts in 1C 8.3 can be to transfer the configuration to a managed (manual) lock management mode. Implemented in version 8.1, the mechanism in the hands of competent specialists solves the problem of lock conflicts during a transaction in 1C.

But it is worth keeping in mind that this action will reduce the level of protection of data from changes while being read by other users. Therefore, if you are not ready to independently control all the locks in the system, do not rush to change the configuration settings.

Quick solution to 1C locking conflict

In the work of an administrator or developer, a situation may arise when there is no time to check an error and search for the root causes of the problem. For example, it is necessary to submit a report or submit data by a certain time, but 1C blocking errors prevent this.

There are two ways to quickly solve the problem:

• Find and end the session that is blocking required data. IN small companies, where the number of 1C users does not exceed a couple of dozen people, this is the optimal solution;
• If you control a system with hundreds of employees, finding the right session without specialized software can take a long time. In this case, it will be much more effective to restart the server.

These solutions are radical and are aimed only at quickly solving the problem and freeing up data for urgent reporting. It can only be eradicated by understanding the reason why a locking conflict arose when executing a 1C transaction. After such actions, it is necessary to find vulnerabilities in the system, optimize the configuration or work of employees. It is not recommended to use such measures on an ongoing basis in case of regular locking conflicts on transactions.