Закрыть AxaptaCOMConnector из AXAPTA

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

Из одной копии AXAPTA 2.5 SP3 подключаюсь к другой копии AXAPTA 2.5 SP3 через AxaptaCOMConnector примерно так:

Com         axCom;
;

axCom =  new COM('AxaptaCOMConnector.Axapta2');
axCom.Logon2(...);

(  )

axCom.logoff();
axCom.stop();
axCom = null;

Однако соединение все равно остается открытым до тех пор, пока не будет закрыта та копия AXAPTA, которая породила соединение.

Как можно "прибить" открытое соединение?

Причем повторное выполнение того же самого кода не вызывает создание нового соединения. Подхватывается ранее созданное соединение. Такое ощущение, что ссылка становится неким внутренним глобальным объектом среды AXAPTA.

[blokva]

а попробуйте вместо

axCom = null;

написать

axCom.finalize();

ибо как по мануалу:

Цитата:

Use finalize carefully. It will destruct an object even if there are references to it.

и

Цитата:

Set the object handle to null to terminate an object. This only destroys the object if there are no other object handles pointing to it.

вполне возможно, что остались какие-то ссылки на ваш объект...

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

Не помогает.

Также не помогает axCom.detach()

Т.е. разрушение объекта происходит. Но не происходит "убиение" созданной сессии. В списке активных пользователей сессия, созданная через ComConnector по прежнему висит.

[raz]

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

PS. Последняя картинка
Как изменить таймаут на портале?

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

Где настравивается TimeOut для Com-объекта?

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

Решение проблемы найдено. Правдо, сильно кривоватое...

Необходимо зарегистрировать AxaptaCOMConnector как COM+. Как правило, в настроечных утилитах этот пункт недоступен, поэтому регистрировать придется вручную.

После этого, процедура закрытия сессии выглядит так:

Com         axCom;
;

axCom =  new COM('AxaptaCOMConnector.Axapta2');
axCom.Logon2(...);

(  )

axCom.logoff();
try
{
	axCom.stop();
}
catch (exception::error)
{
	// в случае ошибки удаляю последнюю строку infolog,
	// которая генерится автоматически ошибкой COM
	if (infolog.line())
	{
		infolog.clear(infolog.line()-1);
	}
}

На методе axCom.stop() генерится ошибка COM - "Не найдено описание события" и соединение балгополучно разрывается.

Если же не давать команду axCom.stop(), то, по непонятным причинам, соединение разорвано не будет.

Кстати, признаком того, что осталось висеть не разорванное в предыдущем сеансе соединение является то, что новое соединение вернет номер сессии равный 65535 и в списке процессов останется висеть процесс dllHost.exe от имени пользователя. Убиение этого процесса также разрывает соединение.

Процесс dllHost.exe - это процесс, вызвываемый при работе COM+. При работе через обычный COM данный процесс не запускается.

[f18]

У Вас 2-х или 3-х уровневая при подключении через ком?

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

Цитата:

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

У Вас 2-х или 3-х уровневая при подключении через ком?

Логика подключения у нас следующая:

Создан класс, со свойством RunOn = Server. Т.е. он запускается всегда только и исключительно на сервере AOS. Вся работа с COM идет через этот класс.

[f18]

Еще один вопос - "зависшее" подключение в форме Активные пользователи в столбце Тип (тип подключения) пишет Thin или NotAOS?

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

Цитата:

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

Еще один вопос - "зависшее" подключение в форме Активные пользователи в столбце Тип (тип подключения) пишет Thin или NotAOS?

Сейчас уже не помню. Чтобы это проверить надо отменить регистрацию Com+

В настоящее время захожу от имени конкретного пользователя и в списке пользователей висит соответствующее имя, указанное первым параметром в logon2() и в столбце тип стоит Thin.

Кажется, раньше было как раз NotAOS.

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

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


Концепция организации подключения в Axapta

В системе Axapta реализована несколько своеобразная концепция организации подключения через Com Connector. Для того чтобы грамотно организовать процесс подключения и отключения к Axapta необходимо хорошо понимать, что именно происходит.

В результате анализа, выполненного вместе с сотрудником фирмы Columbus Виталием Глущенко, я пришел к описанным ниже выводам относительно организации подключения Com Connector в системе Axapta.

Как оказалось, команды logon() и logoff() напрямую не занимаются созданием и разрывом соединений. Они занимаются открытием и закрытием рабочих сессий в ранее созданных соединениях. На факт создания и разрыва соединения эти команды влияют лишь опосредовано.

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

Однако в пределах одного и того же соединения может быть создано до 65535 рабочих сессий. Т.е., например, в списке созданных соединений будет отображено только одно соединение, хотя реально оно будет содержать внутри себя несколько рабочих сессий.


Создание и разрыв соединений

Когда система Axapta получает команду logon() первым делом она смотрит, не было ли уже ранее создано соединений с этим же компьютером. Если таковых соединений не было, то создается специфическое соединение – диспетчер, которое берет на себя вопросы организации соединения с этим же компьютером.

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

Команды logoff() закрывают ранее открытые рабочие сессии. Если в соединении не остается ни одной открытой рабочей сессии, то такое соединение автоматически закрывается.

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

Когда соединение - диспетчер переходит в режим простоя, вступает в силу процесс отключения соединения по истечении определенного времени. Так называемое, время timeout. По истечении этого времени соединение разрывается автоматически.

Значение этого временного интервала устанавливается по-разному, в зависимости от типа регистрации Com-компонента. В случае обычной регистрации Com-библиотеки это время соответствует некоторым глобальным настройкам для Com-объектов. Вероятно, эти настройки прописаны где-то в системном реестре. В случае регистрации Com+ эта настройка находится в свойствах зарегистрированной компоненты Com+.

В обоих случаях, по умолчанию, это время не превышает 3 минут.


Команда stop()

При регистрации Com Connector как Com+ можно использовать специфический метод stop(), который позиционируется как метод, разрывающий соединение. Однако это не вполне верно.

Если Вы зарегистрировали Com Connector как обычную Com – библиотеку, то создание соединений не сопровождается появлением каких-то дополнительных процессов. Все происходит в рамках уже существующих процессов Ax32.exe.

Однако в случае регистрации Com Connector как Com+ создание соединения сопровождается возникновением процесса с именем dllHost.exe. Причем двух процессов. Один – от имени системы (System), а другой, от имени пользователя, установившего соединение.

Ручное «убиение» процесса от имени пользователя приводит к разрыву соединения. Вероятно, именно это и делает команда stop(). Причем этот процесс сопровождается обязательным возникновением исключительной ситуации. Вероятно, это сделано сознательно, как напоминание о том, что Вы выполняете «запрещенную» (в смысле, не желательную) команду.

Однако команда stop() выполнит разрыв соединения только в том случае, если в этом соединении нет ни одной открытой рабочей сессии. Если осталось хотя бы одна не закрытая рабочая сессия, то команда stop() выдаст сообщение об ошибке и разрыва соединения не произойдет. По сути, это просто уменьшение времени простоя соединения, а не реальный разрыв.

При определенных способах подключения, процесс dllHost.exe от имени пользователя не создается. В этом случае, метод stop() также не оказывает никакого действия.


Когда создается новое соединение, а когда сессия внутри соединения

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

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

• Пользователь
• Компьютер
• Тип подключения (Thin, notAOS)

Влияние типа подключения при прочих равных условиях я не проверял. Остановился на переборе первых двух вариантов при использовании подключения в трехуровневой конфигурации (Thin). Значение «notAOS» соответствует двухуровневой конфигурации подключения.

Как и следовало ожидать, команда logon() создает новое соединение при подключении от имени нового пользователя. И открывает новую рабочую сессию внутри существующего соединения при подключении от имени ранее подключившегося пользователя, если подключение осуществляется с того же самого компьютера.

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

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


Аварийное прерывание процесса

До сих пор было описано поведение при штатной работе. Т.е. пользователь открыл рабочую сессию по команде logon() и закрыл ее по команде logoff(). А что произойдет, если произошло аварийное прерывание процесса (например, при сбое питания) и пользователь не смог дать команду logoff()?

Оказывается, поведение зависит от способа регистрации Com Connector. Как обычной Com-библиотеки или как компоненты Com+.

В случае регистрации Com Connector как обычной Com-библиотеки, при сбое питания соединение «повиснет». И как-то его использовать или отключить не будет никакой возможности. Единственный вариант его отключения – это полная остановка AOS. Точнее, вообще всех процессов ax32.exe, axCtrl.exe, axMng.exe запущенных на том компьютере, к которому и было организовано подключение.

В случае регистрации Com Connector как компоненты Com+ при сбое питания происходит автоматическое отключение всех открытых рабочих сессий, а само соединение переходит в режим простоя. Далее оно автоматически будет разорвано при превышении времени timeout или задействовано при создании новых рабочих сессий, если команда logon() будет подана до истечения этого времени.

Как следствие, предпочтительным, с точки зрения возможных аварийных ситуаций, является регистрации Com Connector как Com+ компонент.