Параметри сеансу в BAF: технічний огляд

Параметри сеансу - це спеціальні об'єкти платформи BAF, які дозволяють зберігати значення протягом всього часу роботи користувача з інформаційною базою. Вони є глобальними змінними, доступними з будь-якої точки конфігурації в межах одного сеансу.

Архітектура та місце в системі

Рівні зберігання параметрів сеансу

1. Рівень платформи (BAF - Business Application Framework)

   • Параметри сеансу є частиною ядра платформи BAF

   • Реалізовані на рівні інтерпретатора мови BAF

   • Мають власний механізм типізації та серіалізації

2. Рівень кластера серверів

   • Кожен робочий процес (rphost) має власну область пам'яті для параметрів сеансу

   • Параметри не синхронізуються між різними процесами

   • При перенесенні сеансу на інший процес параметри можуть втрачатися

3. Рівень сеансу бази даних

   • Прив'язані до конкретного з'єднання з базою даних

   • Зберігаються в оперативній пам'яті сервера BAF

Життєвий цикл параметрів сеансу

Етапи життєвого циклу

1. Встановлення сеансу

   • Виклик процедури встановлення параметрів сеансу

   • Ініціалізація значень за замовчуванням

   • Валідація прав доступу

2. Робота з параметрами

   • Читання значень

   • Зміна значень (з обмеженнями)

   • Контроль типів даних

3. Завершення сеансу

   • Автоматичне очищення пам'яті

   • Відключення від бази даних

   • Звільнення ресурсів

Взаємодія з клієнтом та сервером

Тонкий клієнт (Thin Client)

Особливості взаємодії:

• Параметри сеансу зберігаються на сервері

• Клієнт отримує значення через HTTP-запити

• Кешування на стороні клієнта обмежене

• При втраті з'єднання параметри зберігаються на сервері

Товстий клієнт (Thick Client)

Особливості:

• Параметри зберігаються в пам'яті клієнтського процесу

• Пряме з'єднання з базою даних

• Швидший доступ до параметрів

• Менша навантаження на сервер додатків

Веб-клієнт

Роль кластера серверів

Архітектура кластера

Управління параметрами сеансу в кластері

1. Розподіл навантаження

   • Менеджер кластера направляє запити на доступні робочі сервери

   • Параметри сеансу прив'язані до конкретного робочого процесу

   • При перенесенні сеансу параметри можуть втрачатися

2. Ізоляція сеансів

   • Кожен сеанс має власний простір параметрів

   • Параметри одного сеансу недоступні іншим

   • Багатопоточність забезпечує паралельну роботу

3. Масштабування

   Один робочий процес (rphost):

   ├── Сеанс 1: ПараметриСеансу[User1]├── Сеанс 2: ПараметриСеансу[User2]├── Сеанс 3: ПараметриСеансу[User3]└── ...

Представлення на рівні SQL

Зберігання в базі даних

Параметри сеансу НЕ зберігаються безпосередньо в таблицях бази даних. Вони існують тільки в оперативній пам'яті сервера BAF. Однак, для їх ініціалізації часто використовуються SQL-запити:

-- Приклад SQL-запиту для отримання даних користувача

-- (виконується при ініціалізації параметрів сеансу)

SELECT

    Users._IDRRef as UserRef,

    Users._Description as UserName,

    Users._Code as UserCode

FROM _InfoRg23 Users  -- Таблиця користувачів

WHERE Users._IDRRef = @CurrentUserRef

-- При цьому результат зберігається в параметрі сеансу:

-- ПараметриСеансу.ПоточнийКористувач = <результат запиту>

Вплив на SQL-запити

Параметри сеансу впливають на генерацію SQL-запитів:

-- Без параметрів сеансу

SELECT * FROM Document_Sales

WHERE Date >= '2024-01-01'

-- З використанням параметра сеансу РобочаДата

SELECT * FROM Document_Sales

WHERE Date >= @WorkingDate  -- Значення з ПараметриСеансу.РобочаДата

Системні таблички

Платформа BAF створює системні таблиці для управління сеансами:

-- Таблиця активних сеансів (приклад структури)

CREATE TABLE _SessionInfo (

    SessionID UNIQUEIDENTIFIER,

    UserID UNIQUEIDENTIFIER,

    StartTime DATETIME,

    LastActivity DATETIME,

    ApplicationName NVARCHAR(255),

-- Параметри сеансу НЕ зберігаються тут!

)

Технічна реалізація в платформі BAF

Внутрішня архітектура

1. Менеджер сеансів (Session Manager)

   class SessionManager {

       std::map<SessionID, SessionContext*> activeSessions;

       SessionContext* GetSession(SessionID id);

       void CreateSession(SessionID id, UserContext user);

       void DestroySession(SessionID id);

   };

2. Контекст сеансу (Session Context)

   class SessionContext {

       std::map<std::string, Variant> sessionParameters;

       DatabaseConnection* dbConnection;

       UserContext* currentUser;

       Variant GetParameter(const std::string& name);

       void SetParameter(const std::string& name, const Variant& value);

   };

3. Типізована система

   • Автоматичне приведення типів

   • Серіалізація/десеріалізація складних об'єктів

   • Контроль пам'яті та збирання сміття

Механізм доступу

// На рівні конфігурації це виглядає просто:

Значеня = ПараметриСеансу.МійПараметр;

// Але внутрішньо виконується:

// 1. Отримання поточного контексту сеансу

// 2. Пошук параметра в map'і

// 3. Перевірка типів

// 4. Повернення значення або undefined

Обмеження та особливості

Технічні обмеження

1. Розмір пам'яті

   • Немає жорстких лімітів на кількість параметрів

   • Обмежені доступною пам'яттю робочого процесу

   • Великі об'єкти можуть впливати на продуктивність

2. Типи даних

   • Підтримуються всі базові типи BAF

   • Складні об'єкти зберігаються за посиланням

   • Неможливо зберегти файли або потоки

3. Багатопоточність

   • Параметри сеансу не є потокобезпечними

   • Кожен сеанс має власний набір параметрів

   • Немає механізму синхронізації між сеансами

Продуктивність

• Доступ до параметрів сеансу швидкий (пам'ять)

• Ініціалізація може бути повільною (SQL-запити)

• Уникайте зберігання великих таблиць значень

Моніторинг та діагностика

Засоби платформи

1. Консоль кластера

   • Перегляд активних сеансів

   • Статистика використання пам'яті

   • Час життя сеансів

2. Журнал подій

   • Події створення/знищення сеансів

   • Помилки ініціалізації параметрів

   • Проблеми з пам'яттю

3. Технологічний журнал

4. SESN - події сеансів

5. CONN - події з'єднань з базою

6. MEM - події управління пам'яттю

SQL-моніторинг

-- Аналіз блокувань від довготривалих сеансів

SELECT

    blocking_session_id,

    wait_type,

    wait_time_ms,

    resource_description

FROM sys.dm_exec_requests

WHERE blocking_session_id > 0

Проблеми з множинними сеансами та неправильним налаштуванням кластера

Конфлікти параметрів сеансу при множинних підключеннях

Якщо один користувач відкриває декілька сеансів (наприклад, декілька вікон тонкого клієнта або різні додатки), можуть виникати серйозні проблеми:

Сценарій проблеми №1: Різні робочі процеси

Користувач:

├── Сеанс 1 (rphost.exe PID: 1234)

│   └── Параметр “Робоча дата” = 01.06.2025

│   └── Параметр “Оргарнізація” = "ФОП"

│

├── Сеанс 2 (rphost.exe PID: 5678)  ← ІНШИЙ ПРОЦЕС!

│   └── араметр “Робоча дата” = 15.05.2025  ← РІЗНІ ЗНАЧЕННЯ!

│   └── Параметр “Оргарнізація” = НЕ ВСТАНОВЛЕНО

│

└── Результат: Непередбачувана поведінка застосунку

Параметри сеансу BAF — це потужний інструмент, який при правильному використанні значно підвищує продуктивність та зручність роботи з системою. Однак їх ефективність критично залежить від правильного налаштування кластера серверів та архітектури додатка.

Ключові моменти для запам'ятовування:

- Завжди налаштовуйте Session Affinity для стабільної роботи множинних сеансів

- Мінімізуйте обсяг даних у параметрах сеансу та використовуйте тимчасові сховища для великих об'єктів

- Реалізуйте надійну систему ініціалізації з обробкою помилок

- Регулярно моніторте використання пам'яті та очищуйте застарілі сховища

Розуміння цих принципів допоможе уникнути більшості проблем з параметрами сеансу та створити стабільну, масштабовану архітектуру.