On multi-user systems important role plays proper organization structures and setting locks. If not, users will often encounter errors caused by competition for certain system resources. But there is a lock conflict problem that many users are familiar with. Why does a 1C lock conflict occur and how to fix it?
Lock conflict in 1C 8.3 and its meaning
For most users, a 1C lock conflict message means only an error that prevents them from doing their job. They want to get rid of this problem as soon as possible and besiege the IT department with complaints that "1C does not work."
But for system administrators and developers, such a message indicates a possible problem in the configuration structure. Before trying to please users and remove blocks, you need to analyze the situation and understand the cause of the error message.
Causes of blocking errors in 1C
Demonstrative load tests demonstrate that the 1C server can withstand the parallel operation of more than five thousand users. But the ideal conditions for such experiments are unattainable in the daily conditions of large and medium-sized companies. To achieve similar performance and error-free performance, the configuration must be ideally designed and tailored to the specific business processes of the enterprise.
If you do not take ideal options, then 1C lock 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 imply the prohibition of changing the data involved in a transaction launched on behalf of another user;
Errors and shortcomings in the configuration. The structure of standard solutions from the company "1C" takes into account recommendations for maximizing productivity. But third-party developers do not always adhere to high standards, and you can often find the following shortcomings in their code:
- Suboptimal queries;
- Request for balances at the beginning of actions;
- Misunderstanding the purpose of configuration objects and their incorrect use;
- Redundancy inherent in the system or additionally developed locks.
How to fix a lock conflict in 1C 8.3
The system message "lock conflict during the execution of transaction 1C 8.3" 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 submitting quarterly or annual reports, you will get big problems. At best, a slowing system and dissatisfied users. At worst, incorrect output data, which can lead to penalties from regulatory authorities.
The solution to the problem of the conflict of locks in 1C 8.3 can be the transfer of 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 transactions in 1C.
But it should be borne in mind that this action will reduce the level of protection of data from changes in the process of reading them 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 resolution of 1C lock conflict
In the work of an administrator or developer, there may be a situation where there is no time to check the error and find the root causes of the problem. For example, you need to submit a report or submit data by a certain time, and 1C blocking errors prevent this.
There are two ways to quickly solve the problem:
- Find and end the session that has locked the required data. IN small companies, where the number of 1C users does not exceed a couple of dozen people, this is the best solution;
- If you control a system that has hundreds of employees, finding the right session without specialized software may drag on for a long time. In this case, it will be much more efficient to restart the server.
These solutions are radical and aimed only at a quick solution to the problem and the release of data for urgent reporting. It can be eradicated only by understanding the reason due to which a lock conflict arose during the execution of 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 a permanent basis with regular conflicts of locks on transactions.
Hi all!
The other day at work, I encountered a problem with locks, namely, the message "Lock conflict while executing a transaction. The maximum timeout for granting a lock has been exceeded" began to appear.
Obviously, there is no deadlock problem here, it's just that 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 - rebooting the server or searching for a failed session. The first solution is simple and quick, but, as someone already wrote here, you can reboot the server until you get fired. Decided to go the second way.
The first day - the problem appeared in the afternoon, at first it seemed that the problem was in the remote user who was stuck in the Configurator. It looked like the execution just stopped at a point, and the lock, of course, was not released. After a couple of hours, we managed to release the configurator, but the problem did not go away. It was extremely undesirable to kill the configurator forcibly, perhaps they worked in it. After that, Google took over. I found an article on this site, which says how to find locks in the MS SQL DBMS, checked, there were no locks at the DBMS level. Strange. Further there were attempts to adjust those. magazine. Set up, what's 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 through SQL Trace. Even if I find it, then what? I need a session!
Closer to 16:00, when I realized that I couldn’t pull it any further, I made a reboot. In the hope that this will not happen again (and this was the first case 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, dig deeper. I come home, everything is fine. Sadly.
On the third day, I watched a webinar, talked about an interesting and effective method search for a problem. Remembered, but the problem did not arise any more. A week has passed and here it is - again blocking! I rub my hands and start to act.
The first is setting up the log. Yes, I can't do without it, but now I can read it. We set two events: the first is TLOCK, the second is TTIMEOUT. The first displays all blocking events, the second shows blockages that could not be established in the allotted time. In fact, most likely, only TTIMEOUT is enough.
We copy the technical log file to the allotted place, fly to 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 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=8239By 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 - a failed one and some other one. Crashed the session indicated by the technical log. And about a miracle! Everything worked, there is no limit to joy! But, as it turned out later, the session was not hung :), they worked in it. Therefore, for the future, it is advisable to contact the user and warn.
enough in my opinion standard solution enough of a common problem. It is not known why I did not come across it, perhaps due to the fact that I had to look for it on alarm, and when users did not press, then it was not possible to conduct tests - there was no error.
“Lock conflict during transaction execution: The maximum timeout for granting a lock has been exceeded” is a fairly common error in 1C 8.3 and 8.2 associated with competition for the use of resources in the system.
The 1C system allows a large number of users to work in parallel: as load tests show, today this number is not limited to five thousand users simultaneously working in the system. However, so that the 1C 8 database can simultaneously support large quantities about users, the configuration must be properly designed.
Get 267 1C video lessons for free:
Performing a large number of operations
It is likely that some user has started, for example, for a large period in a single transaction. The 1C 8.3 architecture assumes that the system does not allow changing the data that is used in one transaction by another user, and blocks them.
Perhaps this is a temporary error that will stop occurring when another user completes actions on the system. If this error appears frequently, then it is most likely something else.
Configuration error
In addition to errors in the code, there are often methodically incorrect solutions. For example, - it in itself implies the sequential holding of documents. Batch accounting can be replaced by RAUS - this way you will seriously increase the performance of the system.
How to fix this error in 1C 8.3?
In any case, the appearance of the error “Lock conflict while executing a transaction” indicates the need to inspect the system, especially for medium and large information systems in client-server mode (MS SQL, PostgreSQL, etc.). If this is ignored at an early stage, there may be irreversible consequences later, when the operation of the system is especially important (during the reporting period).
For auditing and error correction, it is best to choose a reliable partner. Just call us and we will solve any of your problems in as soon as possible. Details on the page.
Not infrequently, when working in 1C, the error “Lock conflict when executing transactions: The maximum waiting time for granting a lock has been exceeded” occurs. Its essence lies in the fact that several sessions try to simultaneously perform similar actions, affecting the same resource. Today we will figure out how to fix this error.
A large number of operations
First of all, when looking for reasons, you should clarify how many simultaneously working users are in the infobase in which such an error is generated. As we know, their maximum number can be quite large. It's a thousand and five thousand.
The mechanism of locks and transactions is described in the developer's guide. They are used when multiple sessions access the same data at the same time. It is logical that the same data cannot be changed by different users at the same moment.
You should also check if any of the users have started processing for mass data change. It can be like , closing of the month and the like. In this case, after the end of processing, the error will disappear by itself.
Scheduled assignments
It is not uncommon for the cause of the error to lie in, which processes a large amount of data. It is recommended to do such things at night. Schedule the execution of such scheduled tasks during non-working hours.
Thus, both users will work in a stable system, and the scheduled tasks themselves will be completed successfully, since the likelihood of conflicts with user sessions will decrease.
"Stuck Sessions"
The problem of “hung sessions” of users is familiar to almost everyone who has encountered 1C service. The user could have exited the program a long time ago, or closed a document, but his session still remains in the system. The problem is most often single and it is enough to end such a session through the administrator console. The same problems can occur with background jobs.
According to numerous comments on the Internet, such situations are more common when using network security keys. If the situation with "hung sessions" is repeated systematically, this is the reason for a thorough check and maintenance of the system and servers (if the base is client-server).
Errors when writing configuration
All typical configurations are designed qualified specialists and experts. Each system is carefully tested and optimized for faster and more correct work in it.
In this regard, the cause of the error may lie in suboptimal code written by a third-party developer. This may be a "heavy" request that will block data for a long period of time. It is also not uncommon to build algorithms with low performance and violation of logic.
It is highly likely that a lock conflict arose precisely because of developer errors if it arose after updating the program. To check, you can simply “roll back” the improvements, or refactor the code.
Question: UT11.1. Batch creation of Implementations. Lock Conflict
Good afternoon UT11.1 configuration. Client-server option. Default settings for 1C Server and SQL Server. We programmatically form implementations. At the stage of writing documents, a lock conflict periodically occurs. Can you tell me how such issues are resolved? Are transactions with managed locks used? Thank you in advance.
Answer:
do not turn it off) transfer them to the night - there may be a cost calculation and search indexes are considered.
Question: Lock conflict while executing a transaction
Every day, almost at the same time, when holding a document, it pops up for 5-10 minutes given error 1С 8.3.10.26.99 UT11(11.4.1.261):
Lock conflict while executing a transaction:
Microsoft Sql Server Native Client 11.0: Lock request timed out.
HERESULT=80040E31, SqlServer: SQLSTATE=HYT00, state=38, Severity=10, native=1222, line=1
Tell me where to start digging?
Answer:() Enable the profiler at this time on the Lock:Acquired and Lock:Escalation events. Then report back what you got.
Question: Database recovery (lock conflict)
Good afternoon. The base is dying. Server.
It turned out not immediately, because. everything worked except for the document sf issued. And it's not often made. Therefore, the backup is not relevant (apparently several days have passed), they tried to deploy a copy of 2 days ago - it was normal for half a day, and then the same problem got out.
Symptoms: when trying to cancel the SF, we get a lock conflict, even if there is one user in the database. TII (checking logical and referential integrity) fails with a lock conflict, creating a backup through sql management studio - the same ("Timed out waiting for buffer latch type 3 for page").
We want to try to fill in cf a week ago, but there is little hope for something.
Answer: there are problems with the database server, and not 1C, configuration versions, etc. have nothing to do with it.
Perhaps the unattended cheekbone lived as best he could as long as there were enough resources, and now the author begins a new stage in the development of knowledge.
If the size allows - upload to file and start learning sql deeper.
Question: UT10. Lock Conflict
Good afternoon Client-server option. I inherited a heavily modified BitAuto configuration (car service based on UT10). In the handler of the "order-order" document, the main one for receiving masters and managers, the formation of subordinate documents (realization, invoice, invoice requirement), calculation of the salary of mechanics, reservation of goods, if a new document, then the creation of an order - buyer and some other functionality. The database grew and lock conflicts often began to arise. On weekends, when there are fewer people, there are no conflicts.
I suspect that with this amount of analysis, during the document, long time blocks some log of documents, although the log of orders seems to be completely blocked.
If you make your own procedure as the handler of the "OK" button, where you sequentially launch "Processing" and then the procedure, for example, Generate SubordinateDocuments, then CalculateSalary, etc. Not sure if this would help. Adding buttons to which to hang the formation of documents will not work, because. users will forget about it.
Answer:
| Zero |
|---|
| vde69, Duck it's probably some kind of Raru bullshit |
No, this is not Rarus, this is BitAuto
Question: 1c lock conflict when opening document form
SCP
Recently, once every 2-3 days, a block occurs on the Claim-Invoice document. Those. no document of this type is opened. All the time
Other documents work fine.
I did not find any problems in the debugger, I do not have time to stop in any module - immediately there is a conflict of locks.
I suspect some problem in SQL.
Answer: The problem was an index maintenance job that did not complete.
Question: SQL2000 error during transaction execution in 1C77
in MSSQL base 1C77 (release 27) TiS. Regularly when performing postings, an error pops up:
An error occurred while executing the transaction!
SQL State: HYT00
Native:0 Message: Timeout expired.
As a result, the document fails. It can last 20 minutes, or maybe 1 hour.
How to deal with it, where to dig?
Sincerely,
Steve242
The file is attached to the message. Size - 21Kb
Answer:
The regular Windows perfmonitor showed that the Terminal is hellishly loading the C:\ system disk.
Everything else: Memory, CPU - on both servers (terminal and whine) almost no anomalous bursts are displayed.
I created a 2Gb RAMdrive (out of the 12Gb physically available on the terminal server) and I'm trying to redirect the temp system directories of the terminal user profiles there.
until something like that.
Question: Once again, about the Conflict of locks when executing a transaction
Answer:
Question: Blocking when subscribing to RTiU
Answer:
Question: Linux, Postgres, Retail 2.0.5.1 Ukraine RIB in the store - blocking error...
Can someone tell me? I'm setting up a store exchange. Everything works fine, it turns out to make an exchange with hands. 4-5 messages are forwarded. Then I set up the scenario according to the schedule and the swing begins ... The first mistake:
"Error writing data to exchange message file: (Processing.ConvertingDistributedInfobaseObjects.ObjectModule()): Error calling context method (WriteChanges): Lock conflict during the transaction:
Maximum idle time for lock access has been exceeded due to the wait for the session"
All following:
"Error writing data to exchange message file: (Processing.ConvertingDistributedInfoBaseObjects.ObjectModule()): Error when calling context method (WriteChanges): Lock conflict while executing transaction:
The maximum timeout for granting a lock has been exceeded"
Neither reindexing nor closing sessions helps. Blocking in 1C is not worth it. Helps only removal of basis and creation again.
How I understood blocking transits in a DBMS? I use Postgress on Linux, 1 database, 4GB of RAM. If I'm right, the question is Postgress misconfigured or out of memory? Or maybe that's not the problem at all?
Answer:() So fresh is 8.3.10.2375
Question: Blocking error when clearing the information register
I select RS records with a query, then:
RecordSet.Load(QueryResult.Unload()); RecordSet.Clear(); RecordSet.Write();
When I try to write, I get an error:
"Lock conflict while executing a transaction."
The register is not periodic, it is not subordinate to the registrar.
What is the reason for the error?
Answer:() "For some reason, I was sure that the selection is applied only at the time of reading, and what is included in the selection is written accordingly." - Where do you use the word "selection" at least once in your code?
