我们有一个使用 WCF 服务和 ADAM/AzMan 的自定义成员资格提供程序。我们最近看到了很多错误，这似乎与我们的 Web 应用程序的大量使用相对应。
我发现在 Web 应用程序中，每次用户登录时都会对管理员帐户进行更新。
在大量使用的情况下，看起来两个不同的进程正在尝试更新管理员帐户中的配置文件信息。我看到的错误是：
COMException - Cannot create a file when that file already exists.
这是来自阿兹曼。
我的问题是：在 ADAM/AzMan 中尝试对同一记录（甚至是同一个 ADAM 实例）进行并发更新会引发错误，并且该错误是否超出了我应该预期的错误？
编辑我们已经删除了不断更新管理员帐户的代码，这大大减少了错误。我们仍然偶尔会遇到错误。我们有几个应用程序都使用相同的 ADAM 实例。如果其中几个应用程序尝试更新 ADAM 中的数据，这会导致问题吗？
你怎么能在这里阅读
当策略存储在 XML 中时，授权管理器不支持并发。
Authorization Manager 确实利用 Active Directory 来支持并发。Active Directory 和 ADAM 具有 支持并发加减的非事务模型多值或链接的对象属性。在 Active Directory 和 ADAM 中，对对象属性的更改是原子的（在属性级别），因此您永远不会有一个属性是两个更改的网格。Active Directory 使用“最后写入者获胜”机制来确定哪个写入请求将持续存在。属性永远不会合并；一个写入请求（收到的最后一个写入）将始终获胜。对于 AD 链接的属性（例如 Authorization Manager 角色和组成员资格，或操作、任务和角色定义之间的链接），更改是附加的；因此支持同时添加或减少用户或链接和取消链接操作、任务和角色。然而，授权管理器 MMC 管理单元 UI 维护一个客户端缓存，当存储从某个其他 UI 或应用程序更改时，该缓存不会更新；因此，需要多个并发管理员的应用程序需要自定义 UI。
我个人更喜欢使用 SQL Server 作为授权管理器策略存储。如果您创建一个新的基于 SQL 的策略存储并查看相应数据库的内部，您将在几乎所有表中看到RowUpdateTimeStamp该类型的列。timestamp不仅如此，许多表还有额外的类型和触发器ChildUpdateTimeStamp列。这一切都表明，至少基于 SQL 的 Authorization Manager Policy Store是为支持并发而设计的。问题只是这部分并没有真正记录在案，并且不清楚究竟会收到哪些错误/异常。binary(8)XX_UpdateParentTimeStampOnXXX
再说一句。如果您尚未使用IAzAuthorizationStore::UpdateCache，您可以考虑在 AzMan Store 中进行更改之前使用它。