createUserSessions - как работает?

[Lankey]

AX2009 . В хранимой процедуре createUserSessions на стороне sql есть параметр @maxClientId
Кто-нибудь знает, откуда он берет значение(что означает)?
Проблема в том, что номера неактивных сессий (Status=0) в таблице SysClientSessions должны , судя по алготитму, отдаваться новым сессиям
Вот этот момент выбора:

select @first = min(sessionID)
from SysClientSessions with(UpdLock, readpast) 
where sessionId>@maxClientId
and SessionId <>@masterId

, но почему-то вместо этого создаются новые, и из-за этого растет таблица SysClientSessions .... Думаю, что дело в @maxClientId

Спасибо

[Pandasama]

Сам не в курсе, но беглый гуглинг нашёл обсуждение этого параметра здесь
https://community.dynamics.com/forum...9-a2de0b0dfa90
Который дает ссылку сюда:
https://learn.microsoft.com/en-us/pr...ation-commands
Где есть параметр MaxConcurrentSessions

Возможно, это как-нибудь поможет

[Lankey]

Спасибо. Да, я видела ссылку на это обсуждение, но там нет ответа на вопрос. И у нас такая же проблема как там. ClientType=5 не переиспользует номера неактивных сессий, а создает новые

[Logger]

А какую это создает проблему ?
Больше чем 65 тысяч записей не будет.

Какую проблемы вы решаете ?

[Lankey]

Постоянно падали все аосы. То один то другой. По рандому. Обнаружилось, что в этой таблице последняя активная запись с номером 65535 (в момент падения, естественно, становилась неактивной). В таблице записей было намного меньше (пару тысяч), чем 65535. Активных записей из них обычно около 100--200. Судя, по алгоритму, он падал как раз , тк больше 65535 присвоить не мог, но почему-то это сдедать пытался, вместо того, чтобы использовать неактиыне записи с SessionID ниже этой.

Перестарт АОС-ов дело не лечил. После какого-то времени все равно начинали рандомно падать АОСы
Вылечилось основкой всех АОСов и удалением записей из таблицы. Но не ясно, как так получилось, что максимум был достигнут и приводил к таким последствиям?

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

Штатное поведение - это как раз создание новых записей, а не использование "свободных". Если сессию перестали использовать, то она должны быть закрыта (удалена запись) и никак иначе

Там же дальше в хранимке [dbo].[CREATEUSERSESSIONS] возвращает код ошибки

select @first = min(SESSIONID) 
from SYSCLIENTSESSIONS WITH (UPDLOCK,READPAST) 
where STATUS = 0 
	and SESSIONID > @maxClientId 
	and SESSIONID <> @masterId 
	
if (select count(*) from SYSCLIENTSESSIONS where SESSIONID IN (@first)) > 0 
begin 
    (...)
     update (...)
     (...)
     select @sessionid = @first
end
else
begin 
	(...)
		select @max_val = max(SESSIONID)+1 
		from SYSCLIENTSESSIONS WITH (UPDLOCK) 
				
	if (@max_val > 65535) 
		select @sessionid = -3 
	else 
	(...)
end

Т.е. может быть только одна запись с номером сессии 65535. Номер больше создать не даст. Будет ждать, пока не уменьшат количество сессий (я смотрел в dax2012, возможно, в dax2009 этого условия нет)

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


Не вполне ответ на Ваш вопрос, но

Закрыть AxaptaCOMConnector из AXAPTA

В принципе, вывод тот же, что и в обсуждении https://community.dynamics.com/forum...9-a2de0b0dfa90

65535 - это предел. Максимум. Количество соединений должно быть меньше этого числа. Если соединения с номером больше этого числа вообще появились, то это ошибка. Их вообще надо отключать и сбрасывать и искать, почему такая ситуация возникла. Например, в обсуждении - это было подключение из-вне к Axapta. Ну и у меня по ссылке - тоже