Concurrent updates in ADAM/AzMan throwing a strange error

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 开发者_Python百科ADAM can this casue a problem?

How you can read here

Authorization Manager in does not support concurrency when policy is stored in XML.

Authorization Manager does leverage Active Directory for support for concurrency. Active Directory and ADAM have a non-transactional model that supports concurrent additions and subtraction of multi-valued or linked object attributes. In Active Directory and ADAM, changes to object attributes are atomic (at the attribute level) so you never have an attribute that is a mesh of two changes. Active Directory uses a "last writer wins" mechanism to determine which write request will persist. Attributes are never merged; one write request (the last write received) will always win. For AD linked attributes (such as Authorization Manager role and group memberships, or links between operations, tasks, and role definitions) changes are additive; so concurrently adding or subtracting users or linking and unlinking operations, tasks, and roles is supported. However, the Authorization Manager MMC snap-in UI maintains a client-side cache that is not updated when the store is changed from some other UI or application; therefore, applications that require multiple concurrent administrators require a custom UI.

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 RowUpdateTimeStamp columns of the type timestamp in almost all of the tables. More then that, many tables have additional ChildUpdateTimeStamp column of binary(8) type and XX_UpdateParentTimeStampOnXXX triggers. 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.