The current connection does not have a configurator session assigned. Improving the performance of web services. Closing sessions from the configurator

The difference between the concepts of session and connection in 1C:Enterprise 8

What will you learn from this article?

• The correct answer to one of the most popular questions when passing 1C: Expert
• Purpose and features of connections and 1C sessions
• What does session data store?

What are the differences between a session and a connection? This seemingly simple question on the 1C:Expert exam confuses many. Despite considerable programming experience, not every specialist can formulate a clear and correct answer.

In this article we will provide a detailed analysis of this issue. First, let's look separately at the concepts of session and connection in 1C:Enterprise. Please note that the information is relevant for platform versions 8.2.x and 8.3.x.

Session 1C

Let's refer to the administrator's guide. It defines the concept of a session as follows:

Session defines the active user information base and that user's control flow.

We can say that the server cluster does not see users, instead it sees sessions and session data. In principle, the cluster management console does not have a “Users” section; the cluster understands sessions as users.

This confirms the visual representation of the “Sessions” item - the icon is displayed in the form of users.

It should be clarified that the active user does not necessarily mean the client connection, it can also be:

• an instance of the 1C:Enterprise client application
• web application instance where the web client is executed
• outer connection instance obtained from V83.COMConnector object
• 1 instance of background job
• 1 call to the Web service

Session data

Let's consider the concept of session data. The session contains some information such as:

• name of the information base
• session number
• name of the authenticated infobase user
• Interface language
• session parameter values
• temporary storage
• session statistics
• managed application forms information
• some internal platform data

This information is called session data. Moreover, each active user has his own session data, and it is relevant only for the duration of his work. If the user leaves the database (ends the session), his session data is deleted.

Session data is stored on a cluster of servers, the cluster manager is responsible for this, and this is what the session data service is for. To speed things up, session data is cached in worker processes and in thick clients.

When the server cluster is restarted, the session data will be preserved. If the active user has not made a single call to the cluster within 20 minutes and the session is not assigned to the connection, the session is deleted along with its data.

To maintain the session, the thin client and web client access the cluster at least once every 10 minutes.

Connection 1C

Now let's understand the concept of connection. Let's take a look at the administrator's guide again:

A connection is a means of accessing sessions to a cluster of 1C:Enterprise servers, contains a limited set of connection data, and is not identified with the active user.

In other words, a connection allows a session to access the cluster. In this case, the number of connections is limited, and as soon as one is no longer needed by the session, it is returned to the connection pool.

If the session is not accessing the cluster, that is, the user is idle, the connection will not be assigned to him. Thus, a session can exist without a connection.

It should be noted that session data is stored on the server, so if the connection is broken for less than 20 minutes, then this will not affect the session, because the connection is just a means of access.

For example, if you accidentally pull out network cable, the user will not receive an error message if the cable is connected within 20 minutes. In this case, the session will be assigned a new connection and continue running. The user will not even be aware of the problem, except perhaps for a slight freeze.

Connections are also used to communicate between cluster processes, that is, worker processes (rphost) communicate with the cluster manager (rmngr process) using connections rather than using sessions.

Differences between connections and sessions

In order to describe the main difference between these concepts, we will give an analogy.

Let's say that the session is a passenger and the connection is a taxi. When a passenger needs to get home (the session needs to connect to the server), he calls a taxi (the session is assigned a connection from the connection pool).

If, having reached home, the passenger wants to go to work again, but the taxi has already left (after connecting, the connection was disconnected), then the passenger calls a new taxi and goes about his business (a new connection is assigned to the session).

This analogy clearly shows that a session and a connection are not the same thing, and a session can easily survive a connection break.

Burmistrov Andrey

To carry out routine maintenance in the 1C:Enterprise 8 information base, it is often necessary to obtain exclusive access to the database. For example, to perform a database backup or perform routine maintenance on the DBMS server (re-indexing, etc.), you must disconnect all active sessions.

Let's look at a simple way to disconnect users from an infobase using the standard functionality of the 1C:Enterprise server.

Standard functionality

Let me make a reservation right away that we will be talking about the client-server version of 1C:Enterprise 8. To disable sessions, let’s go to the server administration console. There we will find the required information base in the list:

By going to the information security properties, set the option “Session start blocking is enabled.” In this case, you may need to provide a login/password account information base administrator.

Don't forget to set the session lock period. You should also ensure that while sessions are blocked, you need to stop all background jobs. This is done using the “Blocking of routine tasks is enabled” option.

If necessary, you can set the text of the message to users to whom they will be notified 5 minutes before sessions are blocked, as well as the permission code for entering the infobase during the session blocking period.

The permission code can be used to log into the infobase to perform routine maintenance while other sessions are inactive. You need to enter the permission code when connecting to the database using the parameters. For example, this is what the parameter passed to the server will look like if the permission code is "123456".

By logging into the database in this way, we will receive exclusive access to the information base. Other sessions will not be able to join us.

The notification to the user that sessions are blocked looks like this (depending on the message entered by the administrator). It appears every minute 5 minutes before the blocking period.

When the session blocking period begins, a notification appears first:

Afterwards the session ends.

Active sessions can also be disabled by removing them from the list of active sessions. This action is sometimes necessary to terminate hung sessions.

In practice, it is better to communicate about user disconnections in advance to reduce the risk of losing data entered by users but not yet saved.

Need for forced termination User experience mainly occurs in the following cases:

• Updating the information base;
• Adding a new metadata object to the configuration;
• Carrying out preventive and repair work on the server;
• A hung user session is preventing the application from restarting.

In this article we will try to tell you how to end a user session, what tools an administrator has in his or her arsenal to complete this task, which termination options are provided by the file version and which by the client-server version of 1C.

It is important to remember that forcefully terminating a session may result in data loss. So, to avoid unpleasant situations, it is advisable to warn users in advance about the disconnection.

Closing sessions from the configurator

When changes are made to the database structure, dynamic configuration updates are no longer available. And an information window appears on the screen (Fig. 1).

The sequence of actions in this case is obvious:

1. You must click the “End sessions and repeat” button;
2. Wait for the database restructuring window;
3. Click "OK".

It should be noted that changes made to the program code do not require users to shut down, but they will not work on that device without restarting the application on each specific computer.

Ending sessions directly from the program

Most standard 1C products, version 8, have a mechanism that allows you to easily terminate a user's work remotely and provide the administrator with exclusive access to the database. This is the “Blocking connections to infobase” processing.

You can find it at one of two addresses:

1. In one of the submenus of the “Service” section;
2. Going to the Operations->Processing section.

Fig.2

Appearance processing is presented in Fig.2.

Features of this processing:

1. Checking or unchecking the box and clicking the Record button turns user blocking on and off, deleting sessions and preventing new connections from being created;
2. The blocking end time cannot be empty or less than its start time;
3. If the “Permission code” parameter is specified, it can be entered into the startup line to ignore the blocking by specifying “/UC” before the code;
4. If you do not specify the “Permission Code”, then it will be problematic to get into the database before the blocking period expires (in the file version of work, you can try to delete the 1CVcdn file from the database folder);
5. If instead of the parameter “/UC” and a password separated by a space, you specify “/CAllow Users to Work”, where C is Latin, you can completely disable blocking for all users;
6. Button press " Active users, calls up a window with a complete list of users (Fig. 3), from where you can open the “Registration Log” or end the session of each specific user.

Fig.3

The two options above work fine in both file and client-server mode. Further we will consider cases typical only for server work.

Removing users from rdp

It is important to remember that disconnecting user sessions from servers is only possible if you have certain rights to do this.

When working from a remote desktop, you can end user sessions using the standard task manager. Simply interrupting sessions is a bit wrong, but sufficient effective way.

The second option is to use the task manager - remote connection with the ability to manage each specific session and exit the program according to all the rules. This method is long, and no one guarantees that while one user is logging out, the program will not be launched by any other worker.

Removing users via the server console

Having Administrator rights for a 1C server cluster, you must:

Very often, when working in server mode, hung user sessions are not visible through the platform tools; they can only be deleted through the console.

The most radical way to interrupt sessions

A situation where the above methods do not work is extremely rare. But if it occurs, there is another radical way to interrupt connections to the database: physically reboot the server.

Of course, users who did not have time to finish their work and save the data will be extremely outraged by such a shameless attitude, but it is fast and it is extremely effective.

Implemented in version 8.3.9.1818.

In version 8.3.9, we completed a significant number of tasks to optimize various platform mechanisms. Here I would like to talk about one of them. This is an improvement in the performance of web services.

Reusing Sessions

The lack of performance of web services was due to the fact that each call to a web service had significant overhead in creating and terminating the session. Moreover, during creation, each time the SetSessionParameters() handler was executed, which in a typical configuration can be quite “heavy”.

In addition, there was a functional drawback. Web services were stateless. This did not allow us to implement logic that used state persistence between web service calls.

In version 8.3.9 we have improved the web services mechanism (SOAP services, HTTP services, OData services). As a result, their productivity increased approximately 10 times.

We conducted tests on a standard Enterprise Accounting configuration. We have added HTTP services to it that perform selections from the Contractors directory. The test consisted of the client performing 100 consecutive calls to the service. In the old operating mode, this required 29.9 s. In new operating modes, an average of 3 s.

These results were achieved due to the fact that we implemented two different strategies to ensure session reuse:

• Automatic reuse of sessions from the pool;
• Managing sessions using HTTP headers.

With automatic session reuse, the client has no control over the number of sessions and their lifetime. It is simply automatically allocated a session from the existing session pool. This strategy is suitable for highly loaded public services, which are accessed by clients performing template operations and having unified privileges.

For example, this could be the automation of trading activities of remote retail outlets, providing for periods of peak load on the server. The required number of sessions will be allocated for processing. They will be completed as the load drops.

Another example is receiving/placing files in the Document Flow configuration using http services. The same special user can be used for such operations.

The manual session management strategy means that the client independently manages the number of sessions and their lifetime. This strategy is best suited for highly integrated systems within a single organization. You can implement your own algorithm that will control the lifetime of sessions and their number.

Controls

You can determine the need to use one or another strategy in the configuration object tree, and, if necessary, override it in the default.vrd publication file. In the configuration object tree, we have added two new properties to the Web service and HTTP service objects:

• Session Reuse can take the following values: Use Automatically, Use, or Do Not Use. The Use Automatic value enables automatic reuse of sessions from the pool, and the Use value enables session management using HTTP headers.
• In the SessionLifeTime property, you can specify how many seconds the session will be idle before the platform terminates it automatically.

If the client application terminates abnormally (connection is lost or the browser window is closed), 1C: Enterprise 8 client licenses may be blocked.

You can release locked client licenses by rebooting your PC.

If the client application terminates abnormally, the session is held for another 20 minutes. After this, in versions prior to 8.3.5 the session was deleted. Since version 8.3.5, the session falls asleep in the sleeping state by default and is kept for another day. A sleeping session does not occupy the 1C: Enterprise 8 client license.

In version 8.3.5, the session sleep time and the time for deleting an unused sleeping session can be changed using a special program or in the 1C Configurator in the Administration/Infobase Settings dialog by setting the recommended sleeping session parameters:

• time to fall asleep for passive sessions - 300
• end time for sleeping sessions - 10

By the way, you can always see who is sleeping and who is active through the server console on the sessions tab. In the corresponding column “Sleeping” there is a Yes/No sign.

Normally (according to the 1C company version), you can complete work in the web client using the “File” - “Exit” command. Since version 8.3.8, a shutdown command has been added to the application header, next to the button About the program. It is displayed as a hyperlink with the name of the current user. When you click on the hyperlink, a dialog opens with the user name and command To finish work.

The platform pings the client to the 1C server every 5 seconds (packets of 4 bytes are visible). Based on “pings,” the server monitors the integrity of the connection with the client application. The server interprets the absence of pings for about 2 minutes as a connection failure.