следующая проблемма....
для начала описание-----
есть сервер доступа cisco + Radius сервер с авторизацией в MSSQL
в SQL есть таблица активных коннектов, в которую занесены все пользователи.
если пользователь активен у него статус 1, в противном случае - 0.
смена статуса производится radius-сервером по следующему алгоритму:
при подключении пользователя выполняется хранимая процедура авторизации,
которая проверяет логин/пароль и наличие активной сесии , если логин/пароль подошел и активной сессии нет, то за ней выполняется хранимая процедура при старте сессии, которая проверяет наличие пользователя в таблице коннектов. если есть, то пользователю прописывается статус 1, если нет - новый пользователь прописыватся со статусом 1.
при завершении сессии выполняется последняя хранимая процедура, которая подбивает бабки и скидывает статус пользователя в 0.
---- теперь чего плохого-----
не систематически происходит подвисание сессии, то есть 1 не меняется на 0. (по крайней мере пока какую-либо закономерность выявить не удалось)
Статистика такая.:
--- есть пользователи которые ни разу не подвисали,
есть ткаие, которых скидываем в 0 по 5-7 раз за день.
--- Подвисание происходит как при обрыве связи,
так и при штатном завершении сессии.
---
такое ощущение что мы имеем дело с дедлоком таблицы и поэтому изменения в ней не принимаются.
Пробовали поиграть временем жизни транзакции, количеством конкурирующих транзакций, не помогло. Ситуация осложняется невозможностью запустить trace на сервере, по причине его недостаточной производительности.
Если кто сталкивался с подобными граблями расскажите чего делалось для исправления. (ну или в какой области рыть?)
Почему в programming - мне кажется решение проблемы в ошибке при проектировании. Но опыта проектирования для MSSQL у меня нет и я могу не знать каких нть токостей.
Буду благодарен за любую информацию. 10Х
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
