我们有一个使用WCF服务和ADAM / AzMan的自定义成员资格提供程序。我们最近看到了很多错误，这似乎与我们的网络应用程序的更多使用相对应。
我发现每次用户登录到管理员帐户时都会在Web应用程序中显示。
在大量使用情况下，看起来两个不同的进程正在尝试更新管理员帐户中的个人资料信息。我看到的错误是：
COMException - Cannot create a file when that file already exists.
这是来自AzMan。
我的问题是：尝试在ADAM / AzMan中的同一记录（甚至是同一个ADAM实例）上进行并发更新会抛出错误，错误是否超出了我应该预期的错误？
编辑我们删除了不断更新管理员帐户的代码，这大大减少了错误。我们偶尔会遇到一个错误。我们有几个应用程序都使用相同的ADAM实例。如果这些应用程序中有几个试图在ADAM中更新数据，这会产生问题吗？
答案 0 :(得分：0)
如何阅读here
中的授权管理器没有 支持策略时的并发性 以XML格式存储。
授权管理器确实可以利用 Active Directory支持 并发性。 Active Directory和ADAM 有一个非事务模型 支持并发添加和 减值或链接的减法 对象属性。在Active Directory中 和ADAM，对对象属性的更改 是原子的（在属性级别）所以 你永远不会有一个属性 两个变化的网格。活动目录 使用“最后的作家胜利”机制来 确定哪个写请求 坚持。属性永远不会合并; 一个写请求（最后一次写入 收到的）将永远赢。对于AD 链接属性（如 授权管理器角色和组 会员资格，或之间的联系 操作，任务和角色 定义）变化是附加的;所以 同时加或减 用户或链接和取消链接 操作，任务和角色是 支持的。但是，授权 Manager MMC管理单元UI维护一个 未更新的客户端缓存 当商店从一些商店改变 其他UI或应用程序;因此， 需要多个的应用程序 并发管理员需要一个 自定义用户界面。
我个人更喜欢使用SQL Server作为授权管理器策略存储。如果您创建一个新的基于SQL的策略存储并查看相应的数据库，您将在几乎所有表中看到RowUpdateTimeStamp类型的timestamp列。除此之外，许多表格还有ChildUpdateTimeStamp个binary(8)类型和XX_UpdateParentTimeStampOnXXX个触发器列。所有这些都表明，至少基于SQL的授权管理器策略存储旨在支持并发性。问题只是这个部分没有真正记录下来，而且一个人会收到哪些错误/异常并不清楚。
还有一句话。如果您尚未使用IAzAuthorizationStore::UpdateCache，您可以考虑在AzMan商店中进行更改之前使用它。