ADAM/AzMan 中的并发更新引发奇怪的错误
我们有一个使用 WCF 服务和 ADAM/AzMan 的自定义成员资格提供程序。最近我们看到了很多错误，这似乎与我们的网络应用程序的大量使用相对应。
我发现在 Web 应用程序中，每次用户登录时都会对管理员帐户进行更新。
在大量使用情况下，似乎有两个不同的进程正在尝试更新管理员帐户中的配置文件信息。我看到的错误是：
COMException - Cannot create a file when that file already exists.
这是来自 AzMan。
我的问题是：尝试对 ADAM/AzMan 中的同一条记录（甚至同一个 ADAM 实例）进行并发更新是否会引发错误，并且该错误是否高于我应该预期的错误？
编辑我们删除了不断更新管理员帐户的代码，这显着减少了错误。我们仍然偶尔会遇到错误。我们有多个应用程序都使用相同的 ADAM 实例。如果其中多个应用程序尝试更新 ADAM 中的数据，这会导致问题吗？
We have a custom membership provider that uses a WCF service and ADAM/AzMan. We have been seeing a lot of errors lately which seems to correspond to more heavy use of our web aplication.
I discovered that in the web application each time a user logs in an update is being made to the Administrators account.
Under heavy use it looks like two different processes are trying to update profile information in the Adminitrators account. The error I am seeing is:
COMException - Cannot create a file when that file already exists.
This is coming from AzMan.
My question is: Is attempting concurrent updates on the same record (or even just the same ADAM instance) in ADAM/AzMan going to throw an error and is the error above the error I should expect?
EDIT We have removed the code that was constantly updating the admin account and this has significantly reduced the errors. We still run into an error once in a while. We have several applications that all use the same ADAM instance. If several of these apps attempt to update data within ADAM can this casue a problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如何阅读此处
我个人更喜欢使用 SQL Server 作为授权管理器策略存储。如果您创建一个新的基于 SQL 的策略存储并查看相应数据库的内部，您将在几乎所有表中看到
timestamp类型的RowUpdateTimeStamp列。更重要的是，许多表都有额外的binary(8)类型的ChildUpdateTimeStamp列和XX_UpdateParentTimeStampOnXXX触发器。所有这些都表明，至少基于 SQL 的授权管理器策略存储旨在支持并发。问题只是这部分没有真正记录下来，并且不清楚到底会收到哪些错误/异常。再说一点。如果您尚未使用 IAzAuthorizationStore::UpdateCache您可以考虑在 AzMan 商店中进行更改之前使用它。
How you can read here
I personally prefer to use SQL Server as the Authorization Manager Policy Store. If you create a new SQL-based policy store and look inside of the corresponding database, you will see
RowUpdateTimeStampcolumns of the typetimestampin almost all of the tables. More then that, many tables have additionalChildUpdateTimeStampcolumn ofbinary(8)type andXX_UpdateParentTimeStampOnXXXtriggers. All this show that at least SQL-based Authorization Manager Policy Store is designed to support concurrency. The problem is only that this part is not really documented and which errors/exceptions exactly one will receive is not clear.One more remark. If you not yet use IAzAuthorizationStore::UpdateCache you can consider to use it before to made changes in the AzMan Store.