This article describes the process of 1C:Enterprise script execution and the actions the platform performs when script execution starts and stops. These actions include performing transactions, locking and unlocking data for editing it, deleting reusable return values, and logging memory leaks.
What is 1C:Enterprise script execution process
The script execution process (hereafter - the process) is the execution of configuration code, which is written in 1C:Enterprise script, by the platform.
The process starts when 1C:Enterprise platform or the operating system creates a 1C:Enterprise object whose module body is not empty, or calls a module method. Once the module body or method end is reached, the process ends.
- The process of module body execution starts when a client 1C:Enterprise application starts (if the configuration has an application module that is not empty: ordinary application module, external connection module, or managed application module). The module body is executed together with all external calls made from it. Then the module body execution process ends.
- The process starts when the platform calls application module event handlers (BeforeStart, BeforeExit) or idle handlers (set by the AttachIdleHandler method). The process ends when the handler execution ends.
- The process starts when the platform calls an interactive action handler in a form or in a control (OnActivateRow, OnActivateColumn, and so on). The process ends when the handler execution ends.
- The process starts when, after an interactive action is performed, the platform calls the action handler defined in the object module (BeforeWrite, OnWrite, and so on). The process ends when the handler execution ends.
- The process starts when the execution of a server method called from a client starts. The process ends when control is returned to the client.
- The process starts when a script method is called using COM for the first time. The process ends when the method returns control for the last time.
Important: if the script method call stack has a complex structure and includes multiple switches between the platform, the operating system, and the script, the process starts when the first switch from the platform or from the operating system to the script is performed. The process ends when the last switch from the script to the platform or the operating system is performed.
The only exception is the scenario when the debugger pauses script execution and calculates an expression. A new process starts for calculating the expression. The process ends when the calculation is completed.
When a process starts or stops, the platform performs a number of implicit actions, which might affect the configuration functioning.
Many configuration features require concurrent data reading and writing. This is implemented using transactions.
Transactions are started or ended implicitly by 1C:Enterprise objects (for example, when documents are written or posted), or explicitly by global context methods BeginTransaction(), CommitTransaction(), and RollbackTransaction().
A transaction start can be attempted multiple times (implicitly or by using BeginTransaction()). The transaction starts at the first attempt; the next attempts increment the transaction counter. An attempt to end a transaction (implicitly or by using CommitTransaction() or RollbackTransaction()) decrements the transaction counter. The last attempt ends the transaction.
Important: starting a process does not reset transaction counters.
While a process is running, the transaction counter value cannot become less than the stored value. If the execution of CommitTransaction() or RollbackTransaction() method would decrease it further, a "No open transactions" exception is raised.
When a process ends, if the transaction counter value is greater than the stored value, the platform implicitly calls RollbackTransaction() multiple times to make these values equal.
Data locks required for editing
You can manage data locks required for editing using the following methods: LockDataForEdit() and UnlockDataForEdit(). If you call the method LockDataForEdit() without the FormID parameter, the platform releases the lock implicitly when the process ends.
Deleting reusable return values
Common modules might store frequently used values. If the Reuse return values property of a module is set to During call, the stored values are implicitly deleted when the process ends.
Logging memory leaks
The technological log provides the option to monitor specific script fragments for memory leaks during their execution. In particular, it is important to monitor processes for memory leaks. In the following example the technological log configuration file contains the "leaks" element, which is responsible for monitoring memory leaks.
<leaks Collect=1> <point Call="client"/> <point Сall="server"/> </leaks>
In this example the following data is recorded to the technological log: objects that were created but were not released between the start and end of the process on the server (<point Сall="server"/>) and on the client (<point Call="client"/>).
Next page: Handling script errors