Verursacht $ConflictAction Replikationskonflikte?

[Ruedi]

In einer Datenbank traten in letzter Zeit vermehrt Replikationskonflikte auf. Es scheint, als ob das festgelegte Konfliktverhalten Ursache der Konflikte ist. Ich kann dies in einer sehr einfachen DB reproduzieren:

Die DB enthält ein Formular mit einem einzigen Textfeld. Zudem existiert ein Agent, der das Textfeld ändert (z.B. in Grossbuchstaben umsetzt). Das Konfliktverhalten in der Maske ist auf dem Standard "Create Conflicts" belassen. Von der DB wird eine lokale Replik erstellt.

Mit den folgenden Schritten kommt es zu einem Replikationskonflikt:
1. Dokument erstellen
2. Replizieren
3. Dokument mit Agent ändern
4. Replizieren
5. Im Designer Konfliktverhalten auf "Merge/No Conflict" ändern
6. Dokument neu speichern
7. Replizieren => Replik enthält Replikationskonflikt

Bisher glaubte ich, dass Replikationskonflikte nur dann entstehen, wenn in zwei Repliken Änderungen vorgenommen werden. Dass dieser Fall offenbar auch auftreten kann, wenn sich Dokumente in nur einer Replik ändern, ist für mich überraschend.

Falls jemand Zeit und Lust hat, das Problem zu reproduzieren, bin ich gespannt auf Feedback.

Kein Replikationskonflikt tritt auf, wenn ich Punkt "4. Replizieren" auslasse oder im Agenten unter Punkt 3 auch das Feld "$ConflictAction" auf den Wert "3" setze.

Ruedi

[atbits]

Es gibt Replikationskonflikte und Speicherkonflikte.
Notes-Umgangssprachlich spricht man meist von Replikationskonflikten auch wenn es sich um Speicherkonflikte handelt ;-)

Vermutlich spuckt Dein Agent Dir irgendwie in die Suppe und produziert einen Speicherkonflik

\lg David

[Ruedi]

Wäre theoretisch möglich. Aber dann müsste der Speicherkonflikt bereits nach Ablauf des Agenten auftreten und zwar in der DB, in der der Agent läuft.

Tatsächlich wird das Konflktdokument aber in der Replik erstellt und erst nach der Replikation, die auf das Speichern mit dem neuen Konfliktverhalten folgt.

Aber so ganz verstanden habe ich den möglichen Grund noch nicht 

Ruedi

[ascabg]

Hallo,

Kleiner Einwurf, wann Konflikte entstehen.

1. 2 Personen aendern dasselbe Dokument auf demselben Server zur selben Zeit.

2. 2 Personen aendern dasselbe Dokument auf zwei verschiedenen Servern zur selben zwischen der Replikation der beiden Server.

3. wie bei 2. nur durch eine Person

Personen koennen aber auch Agenten sein.


Andreas

[Ruedi]

Auch richtig. Aber die Locking Mechanismen von Notes verhindern mittlerweilen das gleichzeitige Bearbeiten eines Dokuments im UI zuverlässig. Und solange keine Hintergrundagenten beteiligt sind, sind auch andere Save Conflicts eher schwer produzierbar. Kommt dazu, dass in meiner einfachen Modellanordnung nur ich das Dokument ändere.

Ich weiss noch nicht, welchen Einfluss der Agent auf das (spätere) Entstehen meines Replikationskonflikts hat. Relevant sein dürfte, dass im Dokument der einen Replik ein anderes Konfliktverhalten gilt als in der andern Replik. Weshalb Notes aber überhaupt meint, dass hier ein Konflikt aufzulösen sei, ist mir ziemlich schleierhaft.

Ruedi

[m3]

Auch richtig. Aber die Locking Mechanismen von Notes verhindern mittlerweilen das gleichzeitige Bearbeiten eines Dokuments im UI zuverlässig.

Zuverlässig? Rotfl!

[Ruedi]

Ist zwar nicht das Thema, aber trotzdem interessanter Einwurf. Ich bin der Meinung, dass Soft Locking i.d.R. zuverlässig verhindert, dass in der gleichen DB ein zweiter User das Dokument gleichzeitig bearbeitet. Offenbar bist du dediziert anderer Meinung... !?! How come?

Ruedi

[m3]

Probiers mal in einem Cluster, wenn der Lock-Server weg ist ...

[Ruedi]

Ich bezweifle ja nicht, dass es verschiedenste Szenarien gibt, bei denen Locking versagt. Nichtdestotrotz: bei uns funktionierts gut!

Was weisst du übrigens zur ursprünglichen Frage: Replikationskonflikt ohne dass auf mehreren Repliken Änderungen vorgenommen wurden?

Ruedi

[Tode]

Hmmm. Du hast recht, habe ich soeben reproduziert... Sehr seltsam.

Aber eine mögliche Erklärung könnte sein, dass das Dokument, was erstellt wurde, noch nicht das Feld "$ConflictAction" hat... wenn Du das Feld jetzt durch neuspeichern ins Dokument bringst, hast Du zwei Dokumente: Das eine mit "Erstelle Konflikte" und das andere mit "Merge"... und daraus generiert der Replikator tatsächlich einen Replizierkonflikt...

Ob dieses Verhalten "korrekt" ist, vermag ich nicht zu sagen. Da es aber reproduzierbar ist, würde ich auf jeden Fall einen PMR aufmachen.

Nimm dazu Deine Beschreibung (nach der ich auch vorgegangen bin), ergänze Sie aber noch um die Info, welchen Schritt Du auf welcher Replik durchgeführt hast. Und dann sende das an IBM... Das dass so korrekt sein soll, kann ich mir irgendwie nicht vorstellen...

Tode

P.S.: Man braucht keinen Agenten, um das ganze zu reproduzieren, man kann auch im Frontend speichern...

[Ruedi]

Danke fürs Reproduzieren. Einen PMR wollte ich auf jeden Falls machen, falls das Ganze doch mehr als nur heisse Sommerluft ist ... Mit deiner Zusatzinformation kann ich die Anfrage nun noch etwas einfacher und genauer stellen. Mal schauen was IBM dazu meint.

Ruedi

[Peter Klett]

Habe das auch noch mit dem $UpdatedBy ausprobiert:

1. User 1 erstellt ein Dokument in einer Datenbank auf dem Server. $UpdatedBy enthält User 1
2. Replizieren der DB mit lokal
3. User 2 speichert das Dokument lokal ohne Änderung. $UpdatedBy enthält User 1 und User 2
4. User 3 speichert das Dokument auf dem Server ohne Änderung. $UpdatedBy enthält User 1 und User 3

Einstellung Konfliktbehandlung in der Maske: Konflikte erstellen

Replizieren der Datenbank -> Replizier- oder Speicherungskonflikt

Bei allen anderen Einstellung (Konflikte mischen, Mischen/Keine Konflikte, Konflikte nicht erstellen) wird kein Konflikt beim Replizieren erstellt, UpdatedBy enthält jeweils nur 2 der 3 User.

Also auch Abweichungen in noteseigenen Steuerungsfeldern können zu Konflikten führen. Im Falle von $UpdatedBy wäre es jedoch eine Kleinigkeit, den Konflikt notesintern aufzulösen, indem alle Einträge des Feldes gemischt werden (getestet mit 7.03 Client und 6.02 Server).

[Ruedi]

Danke. Irgendwie ist dieses Replikationsverhalten nicht so richtig befriedigend. Ich habe gestern einen PMR mit unten stehendem Inhalt verfasst. Mal schauen, was IBM dazu meint.

Ruedi


PMR:

Modifiying $ConflictAction in an existing document causes replication conflict in next replication.

How to reproduce:
1. Create a very simple database with only one form and one text field. Leave the conflict handling to "Create Conflicts".                      
2. Create a replica of the database
3. Create a document
4. Replicate
5. Modify the document
6. Replicate
7. Modify the form's conflict handling from "Create Conflicts" to "Merge/No Conflict"                                                    
8. Open and save the document (with or without modifications)
9. Replicate

In step 9 a conflict document will be created in the database's replica.