Принудительное завершение сессии

[CHESER85]

Добрый день! Мне необходимо принудительно завершать "лишние" сессии пользователя, при запуске пользователем аксапты. Алгоритм таков, что при запуске аксапты выполняется xSession.terminate. Но к сожалению столкнулся с тем что это действует только при условии что у него есть секретный ключ SysDevelopment. Как обойти это условие, или же завершить сессию другим более экзотическим способом?
Спасибо.

[S.Kuskov]

Как програмно закрыть текущий клиент Аксапты?

[CHESER85]

ну да, согласен, это прокатит если пользователь запустил только одно приложение аксапты. а если, например, 2 или более. и нужно старые сессии отрубить. Т.е. мне надо не текущий клиент убивать а старые сессии закрывать

[dech]

Как насчет контроля за количеством сессий? Т.е. не открывать новые сессии, если не закрыты старые?
В АХ4 этого можно добиться, прописав следующий код в начале метода AppComponent.handleStartupEvent()

#define.SessionsAllowed(3)

SysClientSessions   clientSessions;
;

select count(RecId) from clientSessions
    where clientSessions.UserId     == curuserid()
       && clientSessions.Status     == 1
       && clientSessions.ClientType == 0;

if (clientSessions.RecId > #SessionsAllowed)
{
    box::stop(strfmt("%1 is only allwed %2 AX Client Sessions.  AX Client will close now.",
        xUserInfo::find().name, #SessionsAllowed), "AX Client Sessions exceeded");

    appl.globalCache().set(classstr(Info),identifierstr(Autologoff), true);
    info = new Info();
    info.shutDown(true);
}

Мы даже сделали таблицу с 2 полями: UserId, AllowedSessions.
Разработчикам и консам дали 5 сессий, а остальным по 3. Все довольны.

[sukhanchik]

Цитата:

Сообщение от CHESER85

Добрый день! Мне необходимо принудительно завершать "лишние" сессии пользователя

А Вы можете определить критерий "лишних" сессий? Если да, то почему бы не вызывать тот же метод xSession.terminate от имени какого-нибудь "пакетного" пользователя, т.е. технического пользователя, имеющего все права и от имени которого можно запустить регулярное пакетное задание? И не завязываться на событие "Вход в систему"?

(Сам не пробовал, просто идея в голову пришла. Может этот вариант и не будет работать).

[CHESER85]

да, это похоже на сегодняшний день единственный вариант, чтобы пакетник с правами админа завершал старые сессии остальных пользователей

[CHESER85]

Цитата:

Сообщение от dech

Как насчет контроля за количеством сессий? Т.е. не открывать новые сессии, если не закрыты старые?
В АХ4 этого можно добиться, прописав следующий код в начале метода AppComponent.handleStartupEvent()

#define.SessionsAllowed(3)

SysClientSessions   clientSessions;
;

select count(RecId) from clientSessions
    where clientSessions.UserId     == curuserid()
       && clientSessions.Status     == 1
       && clientSessions.ClientType == 0;

if (clientSessions.RecId > #SessionsAllowed)
{
    box::stop(strfmt("%1 is only allwed %2 AX Client Sessions.  AX Client will close now.",
        xUserInfo::find().name, #SessionsAllowed), "AX Client Sessions exceeded");

    appl.globalCache().set(classstr(Info),identifierstr(Autologoff), true);
    info = new Info();
    info.shutDown(true);
}

Мы даже сделали таблицу с 2 полями: UserId, AllowedSessions.
Разработчикам и консам дали 5 сессий, а остальным по 3. Все довольны.

А если например зависла аксапта и ее аварийно пришлось закрыть? а сессия висеть осталась

[Владимир Максимов]

Цитата:

Сообщение от CHESER85

А если например зависла аксапта и ее аварийно пришлось закрыть? а сессия висеть осталась

В этом случае велик шанс того, что либо Вы в принципе не сможете программно снять сессию, либо сессию в Axapta снимете, но останется висеть сеанс в SQL. В любом случае, позовут админа (или программиста)

Кроме того, опять же, необходимо разобраться в причинах зависания. Зависло по "внешним", не зависящим от кода Axapta, причинам или же кривой код написали?

Т.е., в общем случае, стратегия автоматического закрытия сессий Axapta - это тупиковый путь. Вам по любому придется "пальцем придерживать" этот функционала. Т.е. "вручную" снимать зависшие сессии. Не все, конечно, но это будет достаточно часто. Либо Вы будете постоянно получать не корректную работу функционала, если, например, код Axapta привел к зацикливанию, а сессию Вы прибили.

Поэтому предложение по контролю количества уже открытых сессий одного пользователя лично мне представляется как более разумное решение, по сравнению с автоматическим снятием сессий.

[sukhanchik]

Цитата:

Сообщение от CHESER85

А если например зависла аксапта и ее аварийно пришлось закрыть? а сессия висеть осталась

Цитата:

Сообщение от Владимир Максимов

либо сессию в Axapta снимете, но останется висеть сеанс в SQL.

Тут надо понимать, что снимать сессии в АХ нужно вкупе со снятием сеансов в SQL. Сеанс в SQL висеть сам по себе конечно не будет - он выполнит свою работу и завершится. Но не всегда снятие сеанса в АХ спасет ситуацию.
Пример 1.
Пользователь открыл АХ и ушел домой. На следующий день он не задумываясь - снова запустил АХ (вторую сессию) и сидит в ней работает. В этом случае прибитие первой сессии средствами АХ вполне допустимо, правильно и быстро. Цель - уменьшение количества лишних пользователей, одновременно зашедших в систему (лицензионные ограничения). Есть еще параметр автозавершение, но он не всегда может сработать (он не сработает, если Аксапте для закрытия формы нужно выдать запрос пользователю - типа Сохранить? Да/Нет)

Пример 2. Пользователь открыл АХ, запустил долгостороящийся отчет / долгую периодическую операцию. При этом тормоза связаны с алгоритмом, написанном на Х++ (не с БД и не с огромной транзакцией). Пользователь запускает вторую сессию АХ, на первую плюет, а админам (из-за лицензионных ограничений) эту зависшую сессию надо удалить. В этом случае прибитие первой сессии средствами АХ вполне допустимо, правильно и быстро. Но тут нужно точно знать, что проблема не в БД, а обычно, если уж точно знают, что проблема не в БД, то уж исправляют алгоритм.

Пример 3.
Пользователь открыл АХ, запустил долгостороящийся отчет / долгую периодическую операцию / открыл тяжелую форму. При этом тормоза связаны с БД. Возможно, что идет смешение с предыдущим примером - мелкие запросы выполняются 100500 раз и с т.з. пользователя - все виснет. И пользователь решает тоже снять задачу. В этом случае:
- если есть очень большая транзакция, то по-любому пойдет ее откат (а это тоже время)
- если запустилась большая хранимая процедура (или просто тяжелый запрос, в т.ч. неиндексированный), то снятие сеанса АХ вообще ничего не даст - пока процедура не отработает и не откатится - таблички, которые в ней задействованы - будут "под нагрузкой", т.е. повторный запуск этой хранимой процедуры из новой сессии АХ не даст ровным счетом ничего, кроме дополнительной нагрузки на сервер БД.
- если запустилось построение большого и толстого индекса, то снятие сеанса АХ опять-таки - ничего не даст.

Поэтому тут надо понимать, что снимая сеанс АХ - необходимо до этого кильнуть все пользовательские спиды этого сеанса на БД, потому что иначе все будут терпеливо ждать окончания выполнения запроса, а затем ждать отката (ROLLBACK). Удаление (KILL) спидов на БД позволит сократить время ожидания выполнения запроса (сразу пойдет ROLLBACK). Для крупных БД - это актуально. Для маленьких - нет.