Смешивание переменных сеанса в ASP.NET?

пока все возможно. . . .

Нет, если вы не сохраняете состояние сеанса на сервере sql или каком-либо другом вне хранилища процессов, а затем возитесь с ним. . .

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

Какое поведение вы наблюдаете? И уверены ли вы, что в переменных, о которых вы говорите, нет статики?

Сеанс привязан к куки-файлу пользователя, шансы на сбой в обычном сценарии очень маловероятны, однако могут возникнуть проблемы при использовании распределенного состояния сеанса.

Это невозможно. Сеансы привязаны к создателю.

Вы хотите перепутать, или у вас есть случай, когда все выглядит перепутанным?

Дополнительная информация:

У меня есть приложение, которое берет идентификатор пользователя / пароль со страницы входа и сохраняет его в переменной сеанса. Я вставляю его в строку подключения для выполнения вызовов SQL Server.

Когда таблица обновляется, мы используем "system_user" в базе данных, чтобы идентифицировать пользователя "последнего обновления". Мы наблюдаем странное поведение, при котором пользователь, которого мы ожидаем увидеть в списке, неверен и показывает кого-то другого.

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

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

Я предполагаю, что вы повторно используете статическое поле в классе для хранения строки подключения. Эти статические поля повторно используются в нескольких запросах IIS, поэтому вы, вероятно, когда-либо увидите только последнего вошедшего в систему пользователя в разделе «Последнее обновление до».

Кстати, если у вас нет ДЕЙСТВИТЕЛЬНО веской причины для этого, вам не следует подключаться к БД таким образом. Вы не позволяете себе использовать пул соединений, который может снизить производительность при высоких нагрузках.

Чтобы ответить на ваш исходный вопрос: сеансы привязаны к идентификатору, который помещается в файл cookie. Этот идентификатор генерируется с использованием некоторых криптографических процедур со случайными числами. Не гарантируется, что он будет уникальным, но очень маловероятно, что он когда-либо будет дублироваться в течение жизни сеанса. Даже если ваши сеансы длятся полные рабочие дни. Вероятно, потребуются годы, чтобы действительно популярный сайт даже сгенерировал дубликат ключа (нет статистики или фактов, подтверждающих это).

Сказав все это, похоже, ваша проблема не в том, что значения сеанса смешиваются. Первое, на что я хотел бы обратить внимание, - это пул соединений. ADO объединяет соединения по умолчанию, но если вы запрашиваете соединение с именем пользователя / паролем, которого нет в пуле, он должен предоставить вам новое соединение. Подсказка, что в будущем может стать узким местом производительности, если ваш сайт очень большой. Прошло некоторое время с тех пор, как я работал с SQL Server, в Oracle есть вызов, который можно сделать для переключения личности пользователя. Я был бы удивлен, если бы в SQL Server не было эквивалента. Вы можете попробовать подключиться к своей БД с общим именем пользователя / паролем, а затем выполнить этот вызов переключения идентификации, прежде чем вы вернете соединение остальной части вашего кода.