Gleichzeitige Updates in ADAM/AzMan werfen einen seltsamen Fehler

Question

Wir haben einen benutzerdefinierten Mitgliedschaftsanbieter, der einen WCF-Dienst und ADAM/AzMan verwendet. Wir haben in letzter Zeit eine Menge Fehler gesehen, die einer stärkeren Nutzung unserer Webapplikation zu entsprechen scheinen.

Ich entdeckte, dass in der Webanwendung jedes Mal, wenn sich ein Benutzer anmeldet, ein Update an das Administratorkonto vorgenommen wird.

Bei starker Nutzung scheinen zwei verschiedene Prozesse versucht zu haben, Profilinformationen im Administratorkonto zu aktualisieren. Der Fehler, den ich sehe, ist:

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

Dies kommt von AzMan.

Meine Frage ist: Wird versucht gleichzeitige Updates auf dem gleichen Datensatz (oder sogar nur die gleiche ADAM-Instanz) in ADAM/AzMan einen Fehler zu werfen und ist der Fehler oberhalb des Fehlers, den ich erwarten sollte?

BEARBEITEN Wir haben den Code entfernt, der das Administratorkonto ständig aktualisiert hat und das hat die Fehler erheblich reduziert. Wir stoßen immer wieder auf einen Fehler. Wir haben mehrere Anwendungen, die alle dieselbe ADAM-Instanz verwenden. Wenn mehrere dieser Apps versuchen, Daten in ADAM zu aktualisieren, kann dies ein Problem sein?

Answer 1

Wie Sie here

Autorisierungs-Manager in nicht Unterstützung Gleichzeitigkeit lesen kann, wenn Politik in XML gespeichert ist.

Autorisierung Manager nutzt Active Directory für die Unterstützung für Nebenläufigkeit. Active Directory und ADAM haben ein nicht transaktionales Modell, das gleichzeitige Ergänzungen und Subtraktion von mehrwertigen oder verknüpften Objektattributen unterstützt. In Active Directory und ADAM sind Änderungen an Objektattributen atomare (auf der Attributebene) so Sie haben nie ein Attribut, das ein Netz von zwei Änderungen ist. Active Directory verwendet einen "Last Writer Wins" -Mechanismus zu bestimmen, welche Schreibanforderung wird bestehen bleiben. Attribute werden nie zusammengeführt; eine Schreibanforderung (die letzte Schreiboperation empfangen) wird immer gewinnen. Für AD verknüpfte Attribute (z. B. Autorisierungs-Manager-Rolle und Gruppe Mitgliedschaften oder Verknüpfungen zwischen Operationen, Aufgaben und Rolle Definitionen) Änderungen sind additiv; so gleichzeitig hinzufügen oder subtrahieren Benutzer oder Verknüpfung und Aufhebung der Verknüpfung Operationen, Aufgaben und Rollen ist unterstützt. Die Autorisierungs Manager MMC-Snap-In-Benutzeroberfläche verwaltet jedoch einen clientseitigen Cache, der nicht aktualisiert wird, wenn der Speicher von einigen anderen Benutzeroberfläche oder Anwendung geändert wird; Daher benötigen Anwendungen, die mehrere gleichzeitige Administratoren erfordern, eine benutzerdefinierte Benutzeroberfläche .

Ich persönlich bevorzuge es, SQL Server als Authorization Manager Policy Store zu verwenden. Wenn Sie einen neuen SQL-basierten Richtlinienspeicher erstellen und in die entsprechende Datenbank schauen, werden in fast allen Tabellen RowUpdateTimeStamp Spalten vom Typ timestamp angezeigt. Mehr als das, viele Tabellen haben zusätzliche ChildUpdateTimeStamp Spalte von binary(8) Typ und XX_UpdateParentTimeStampOnXXX Auslöser. All dies zeigt, dass mindestens der SQL-basierte Authorization Manager-Richtlinienspeicher so konzipiert ist, dass er die Parallelität unterstützt. Das Problem ist nur, dass dieser Teil nicht wirklich dokumentiert ist und welche Fehler/Ausnahmen genau einer erhalten wird, ist nicht klar.

Eine weitere Bemerkung. Wenn Sie IAzAuthorizationStore::UpdateCache noch nicht verwenden, können Sie es verwenden, um Änderungen im AzMan Store vorzunehmen.