Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
[win32] [mssql][radius] отбой - вроде разобрался :)))) 24.09.03 22:33 Число просмотров: 1124
Автор: hamstr Статус: Незарегистрированный пользователь
|
дело оказалось в дедлоке.
организовал где надо вложенную транзакцию и ручной коммит в конце. пока работает без блокировок. :))))
|
|
<programming>
|
[win32] [mssql][radius] подвисание сессии пользователей. 15.09.03 15:25
Автор: hamstr Статус: Незарегистрированный пользователь
Отредактировано 15.09.03 16:34 Количество правок: 2
|
следующая проблемма....
для начала описание-----
есть сервер доступа cisco + Radius сервер с авторизацией в MSSQL
в SQL есть таблица активных коннектов, в которую занесены все пользователи.
если пользователь активен у него статус 1, в противном случае - 0.
смена статуса производится radius-сервером по следующему алгоритму:
при подключении пользователя выполняется хранимая процедура авторизации,
которая проверяет логин/пароль и наличие активной сесии , если логин/пароль подошел и активной сессии нет, то за ней выполняется хранимая процедура при старте сессии, которая проверяет наличие пользователя в таблице коннектов. если есть, то пользователю прописывается статус 1, если нет - новый пользователь прописыватся со статусом 1.
при завершении сессии выполняется последняя хранимая процедура, которая подбивает бабки и скидывает статус пользователя в 0.
---- теперь чего плохого-----
не систематически происходит подвисание сессии, то есть 1 не меняется на 0. (по крайней мере пока какую-либо закономерность выявить не удалось)
Статистика такая.:
--- есть пользователи которые ни разу не подвисали,
есть ткаие, которых скидываем в 0 по 5-7 раз за день.
--- Подвисание происходит как при обрыве связи,
так и при штатном завершении сессии.
---
такое ощущение что мы имеем дело с дедлоком таблицы и поэтому изменения в ней не принимаются.
Пробовали поиграть временем жизни транзакции, количеством конкурирующих транзакций, не помогло. Ситуация осложняется невозможностью запустить trace на сервере, по причине его недостаточной производительности.
Если кто сталкивался с подобными граблями расскажите чего делалось для исправления. (ну или в какой области рыть?)
Почему в programming - мне кажется решение проблемы в ошибке при проектировании. Но опыта проектирования для MSSQL у меня нет и я могу не знать каких нть токостей.
Буду благодарен за любую информацию. 10Х
|
|
[win32] [mssql][radius] отбой - вроде разобрался :)))) 24.09.03 22:33
Автор: hamstr Статус: Незарегистрированный пользователь
|
дело оказалось в дедлоке.
организовал где надо вложенную транзакцию и ручной коммит в конце. пока работает без блокировок. :))))
|
|
|
подробно о проекте
Анализ криптографических сетевых...
