Одновременные обновления в ADAM / AzMan выдают странную ошибку

Question

У нас есть пользовательский поставщик членства, который использует службу WCF и ADAM / AzMan.В последнее время мы видим много ошибок, которые, по-видимому, соответствуют более интенсивному использованию нашего веб-приложения.

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

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

COMException - Cannot create a file when that file already exists.

Это исходит от AzMan.

Мой вопрос: предпринимается ли попытка одновременного обновления одной и той же записи (или даже одного и того же экземпляра ADAM) вADAM / AzMan собирается выдать ошибку, и эта ошибка выше ошибки, которую я должен ожидать?

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

Answer 1

Как читать здесь

Диспетчер авторизации в не поддерживает параллелизм при хранении политики в XML .

АвторизацияМенеджер использует Active Directory для поддержки параллелизма.Active Directory и ADAM имеют нетранзакционную модель, которая поддерживает одновременное сложение и вычитание многозначных или связанных атрибутов объекта.В Active Directory и ADAM изменения атрибутов объекта являются атомарными (на уровне атрибута), поэтому у вас никогда не будет атрибута, представляющего собой сетку из двух изменений.Active Directory использует механизм «последних побед писателя», чтобы определить, какой запрос на запись будет сохранен.Атрибуты никогда не объединяются;один запрос на запись (последняя полученная запись) всегда побеждает.Для связанных атрибутов AD (таких как роль диспетчера авторизации и членство в группах или связи между операциями, задачами и определениями ролей) изменения являются аддитивными;поэтому одновременное добавление или вычитание пользователей или связывание и удаление операций, задач и ролей поддерживается.Однако интерфейс оснастки MMC диспетчера авторизации поддерживает клиентский кэш, который не обновляется при изменении хранилища по сравнению с другим интерфейсом или приложением;поэтому приложениям, которым требуется несколько одновременных администраторов, требуется пользовательский интерфейс.

Я лично предпочитаю использовать SQL Server в качестве хранилища политик диспетчера авторизации.Если вы создадите новое хранилище политик на основе SQL и загляните внутрь соответствующей базы данных, вы увидите RowUpdateTimeStamp столбцы типа timestamp почти во всех таблицах.Более того, многие таблицы имеют дополнительный столбец ChildUpdateTimeStamp типа binary(8) и триггеры XX_UpdateParentTimeStampOnXXX.Все это показывает, что по крайней мере хранилище политик диспетчера авторизации на основе SQL предназначено для поддержки параллелизма .Проблема только в том, что эта часть на самом деле не документирована и какие ошибки / исключения получит ровно одна, неясно.

Еще одно замечание.Если вы еще не используете IAzAuthorizationStore :: UpdateCache , вы можете использовать его до внесения изменений в хранилище AzMan.