Проблема с SysClientSessions

[trace]

Требуется ограничить число открывемых пользователем сессий Аксапты(4.0) .
В методе startupPost() класса Application написана проверка:
while select clientSessions where
clientSessions.userId == curUserId()
&& clientSessions.Status == 1
&& clientSessions.SessionId!= sessionid()
........
Когда заходиш в аксапту под юзером Admin, то все работает, а если заходиш под другим, то этот селект вообще пролетает и входит в аксапту независимо от количества открытых сессий. Как быть?

Заранее спасибо.

[gl00mie]

Quote:

Originally Posted by trace

Требуется ограничить число открывемых пользователем сессий Аксапты(4.0). Как быть?

По крайней мере, для 3-ки был такой вариант, как ограничить количество входов пользователя.

[trace]

Quote:

Originally Posted by gl00mie

По крайней мере, для 3-ки был такой вариант, как ограничить количество входов пользователя.

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

[gl00mie]

Quote:

Originally Posted by trace

Дело в том, что мне нужно убивать предыдущую сессию, а не новую открытую.

Мне кажется, это очень неудачная идея; если ее вам подсказали аналитики или, того хуже, сами пользователи - подумайте дважды... Пользователь может запустить какую-нить длительную операцию (создание отчета, разноску журнала, еще что-то) - не в пакетном задании, а непосредственно в своей сессии и, "покурив" минуту-другую, попытаться запустить второй экземпляр клиента. В результате предыдущий клиент по вашей логике прибьется, и запущенная операция прервется с откатом транзакции, если таковая будет начата в ходе обработки. Хорошо, если это будет длительное создание отчета, а если какая-нить разноска? Вы уверены, что пользователи хотят именно этого и будут адекватно воспринимать подобное поведение системы при запуске второго клиента?
Более того, надо быть очень аккуратным при таком подходе, ведь пользователи могут быть и служебные - какие-нить proxy-пользователи для бизнес-коннектора. В результате при таком поведении системы любой функционал, их использующий, будет постоянно прибиваться при запуске второй сессии. Я точно не скажу, но вроде Enterprise Portal требует (требовал в 3-ке) двух COM-лицензий и, соотв., двух одновременно работающих сессий COM-коннектора. Подумайте об этом.

[trace]

Quote:

Originally Posted by gl00mie

Мне кажется, это очень неудачная идея; если ее вам подсказали аналитики или, того хуже, сами пользователи - подумайте дважды... Пользователь может запустить какую-нить длительную операцию (создание отчета, разноску журнала, еще что-то) - не в пакетном задании, а непосредственно в своей сессии и, "покурив" минуту-другую, попытаться запустить второй экземпляр клиента. В результате предыдущий клиент по вашей логике прибьется, и запущенная операция прервется с откатом транзакции, если таковая будет начата в ходе обработки. Хорошо, если это будет длительное создание отчета, а если какая-нить разноска? Вы уверены, что пользователи хотят именно этого и будут адекватно воспринимать подобное поведение системы при запуске второго клиента?
Более того, надо быть очень аккуратным при таком подходе, ведь пользователи могут быть и служебные - какие-нить proxy-пользователи для бизнес-коннектора. В результате при таком поведении системы любой функционал, их использующий, будет постоянно прибиваться при запуске второй сессии. Я точно не скажу, но вроде Enterprise Portal требует (требовал в 3-ке) двух COM-лицензий и, соотв., двух одновременно работающих сессий COM-коннектора. Подумайте об этом.

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

[mazzy]

Quote:

Originally Posted by gl00mie

подумайте дважды...

очень грамотное замечание. ап-солютно согласен.

Quote:

Originally Posted by trace

бывают случаи

ну дык и решайте эти отдельные случаи. зачем шашкой то махать?

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

Quote:

Originally Posted by trace

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

Очень часто при зависании сессии ни сам пользоватиль, ни Axapta не смогут ее отключить. Помогает только внешнее отрубание процесса. В худшем случае, перезагрузка AOS. Т.е. программное отключение в критических ситуациях - не работает, хотя и ошибок не вызывает.

Это значит, что, в общем случае, единственное что можно сделать - это сообщить пользователю, что у него уже есть открытые сессии. И на этом все.

Отслеживать такие "подвисшие" сессии должен администратор, поскольку сам пользователь часто просто не имеет физической возможности как-то снять "подвисшую" сессию.