Я также сталкивался с этой проблемой, и после некоторого расследования она возникает чаще, когда у вас есть более одного экземпляра, и вы пытаетесь сделать вызовы в быстрой последовательности в одном сеансе.(например, если у вас было поле автозаполнения и при каждом нажатии клавиши выполнялись вызовы ajax)
Это происходит потому, что при попытке доступа к данным сеанса, прежде всего, веб-сервер блокирует этот сеанс.Когда запрос завершен, он снимает блокировку.Поставщик услуг таблицы обновляет это состояние блокировки, обновляя поле в таблице.Я думаю, что происходит, что Instance1 загружает строку сеанса, затем Instance2 загружает строку сеанса, Instance1 сохраняет обновленное состояние блокировки, и когда Instance2 пытается сохранить состояние блокировки, он получает ошибку, потому что объект находится не в том же состояниикак при загрузке (ETag больше не совпадает).
Вот почему найденное исправление остановит возникновение ошибки, потому что, указав "*" в AttachTo, когда Instance2попытка сохранить блокировку отключит проверку ETag (и перезапишет изменения, сделанные Instance1).
В нашей ситуации мы изменили провайдера, чтобы мы могли отключить сеанс для определенных путей (вызов ajaxчто давало нам, чтобы наши проблемы не нуждались в доступе к данным сеанса, равно как и к загрузке изображений), что может быть вариантом для вас в зависимости от того, что вызывает вашу проблему.
К сожалению, TableStorageSessionStateProvider является частьюпримеры проектов и так нет (насколько я знаю, ноЯ с радостью скажу иначе) официально поддерживается Microsoft.У него есть другие проблемы, например, тот факт, что он не очищает данные сеанса после истечения сеанса, поэтому у вас останется много мусора в таблице сеансов и контейнере BLOB-объектов, которые вам придется очиститьспособ.