"Uns rennt die Zeit davon" - DB-Modified-Datum weit in der Zukunft

[eknori]

IBM Reaktion

Forwarded to development.

[ghostmw]

... hab noch was dazu beizutragen.

Wir haben eine große Applikation bei der wir den RnRMgr-Task mit benutzen, indem wir einige Sache mit der Ressourcen-DB machen, die man so normalerweise nicht kann, wie z.B. Reservierungen mit Karenzzeiten versehen (auch wenn sie aus dem Kalender kommen), dazu ist es u.a. notwendig selbst Notices (NoticeType="U", RQStatus = "T") zu versenden.

Dabei ist uns die Zeitverschiebung das erste Mal aufgefallen ... dann haben wir das Beispiel s.o. konstruiert und siehe da es liegt nicht an unserem Code (puuuuh...).

Sollen in einer DB aus der "Zukunft" per RnRMgr-Task Reservierungen (mit Zukunftsdatum) verbucht werden, passiert nichts, wenn es sich um Aktualisierungen handelt (NoticeType = "U" und RQStatus = "T").

Es gibt auf alle Fälle durcheinander in der busytime.nsf bzw. clubusy.nsf und auch was schlussendlich verbucht wurde.

Danke auch von meiner Stelle an alle fürs Testen der versch. Versionen ...  


Neues von der IBM:

...
I work on the Application Development team in Lotus Support and I       
received the details of this issue this afternoon. I am currently       
investigating and will contact you again shortly with my initial       
findings.     
...

[ghostmw]

... noch was neues, den Cluster steckt das Modified-Datum in der Zukunft auch an.

Ich habe dieselbe Datenbank im Cluster vorliegen.

Starte auf dem einen Clustermember den Agenten, dessen Modified-Datum liegt in der Zukunft.
Durch die Clusterreplikation das Modified-Datum der Cluster-Datenbank auch, nicht ganz soviel aber auch mehrere Minuten bei 10.000 Dokumenten.

Das scheint wirklich ein größeres Problem zu sein ...

[Peter Klett]

Hab das auf einem Server 6.0.2 auch mal laufen lassen. Gleiches Ergebnis, also kein Bug von 8.5.x, sondern schon älter

[ghostmw]

... es gibt was neues von IBM.

...
I have carried out further research into this issue and can confirm that the behaviour you are seeing has been reported previously in the following SPR (Software Problem Report):
SPR #DWHN85CCVH: Modified time of document created is set in the future by approximately 30 minutes.

The SPR describes an identical case, where an agent creating many document updates results in documents with a modified time in the future, with the same for the database modified time. This was investigated by Lotus Software Quality Engineering who determined this not to be a bug but the correct behaviour. This behaviour is necessary to ensure the correct functioning of replication, which requires a unique time for each change. The agent updates the document and saves it each time. Notes/Domino is designed to increase the time of a database when rapid document changes are made in order to preserve the uniqueness for replication. If you were to make the document save outside the loop so that it saves just once then you would not see this effect. For the code provided here the database will continue to mark documents modified in the future until there is no further document activity and the system time has time to catch up to the future time.

Another similar SPR describes the effect as follows:
After the real server time reaches the incorrect 'modify time' then 'creation time' and 'modify time' become the same and will match with the real server time.
...

... das ist genau das, was mir Kopfzerbrechen macht.
"Works as designed" ... aber wie verhält sich aber dabei der RnRMgr, die Replikation etc..

Ich werde das bei der IBM nochmals detailliert nachfragen und dann wieder informieren.

[eknori]

Also ist das ein Wert, der in der UI überhaupt nichts zu suchen hat, weil man damit eh nichts anfangen kann/soll und der nur für die systeminterne Verarbeitung gedacht ist.

[ghostmw]

... das könnte man meinen.

Die spannende Frage ist jetzt aber ... was passiert, wenn ich in meiner Reservierungs-DB z.B. bei allen Reservierungen ein neues Feld initial setze oder sonstige Änderungen vornehmen. Angenommen ich habe 10.000 Reservierungen.

Kommt dann der RnRMgr-Task durcheinander ? Ignoriert er ggf. Reservierungen, die mit der richtigen realen Zeit abgespeichert werden, weil das Datum für den Raum in der Zukunft ist ?

Ich werde es mal versuchen nachzubauen und die Ergebnisse posten.

In der Zwischenzeit habe ich die IBM mal drum gebeten eine Stellungnahme abzugeben, inwieweit die einwandfreie Funktion der Systemtasks wie Replicator, RnRMgr oder AMgr beinträchtigt sind.

[Ralf_M_Petter]

Das ist doch völlig normal. Das passiert in jedem replizierenden System gleich.

Du änderst 100.000 mal das selbe Dokument. Domino muß für jeden dieser Schreibzugriffe die Änderungszeit erhöhen. Wenn nun die Schreibzugriffe schneller erfolgen als die Auflösung des Zeitfelds ist, muß er die Zeit künstlich erhöhen.

Gehen wir der Einfachheit davon aus, dass das Zeitfeld der letzten Änderung eine Auflösung von Millisekunden hat. und 10 Schreibzugriffe pro Millisekunde erfolgen. Dann wechselt die Uhrzeit nur bei jedem 10 Schreibzugriff. Damit Domino aber für die Replizierung aber den Schreibzugriff erkennt muß er die Zeit künstlich um eine Millisekunde erhöhen. Wie gesagt nur ein Beispiel, habe keine Ahnung wie groß die Auflösung eine Zeitfelds in Domino ist. Könnte man aber mit Tools problemlos herausfinden.

In der Praxis wird dieses Problem kaum auftreten, da ein so oftes Schreiben des Dokuments sehr schlechter Programmierstil ist.

Grüße

Ralf

[ghostmw]

... spannend wirds aber, wenn z.B. der RnRMgr sich an einem Dokument die Zähne ausbeißt, und es aufgrund der erneuten Speicherung immer und immer wieder abspeichert in einer Endlosschleife, das hatten wir auch schon mal.

Ich bin grade aktuell mit der IBM noch dran herauszufinden, was im Zusammenhang mit Reservierungen aus dem Kalender und der Reservierungs-DB in der "Zukunft" passiert.

Ich meine, dass Raumreservierungen und Updates aus dem Kalender heraus nicht vom RnRMgr verarbeitet wurden.

[ghostmw]

Moin,

wollte mich nochmals kurz rückmelden in der Sache.

Ich habe in einer Standardreservierungs-Datenbank nun mal versucht den RnRMgr aus dem Gleichgewicht zu bekommen.

Also zuerst täglich einen Kalendereintrag per Agent erstellen lassen, insgesamt 25.000 Stück.
Damit ist die Datenbank ein paar Stunden in der Zukunft.

Und dann habe ich alles Mögliche versucht:

• Besprechung aus dem Kalender heraus mit Raum gebucht. => wurde sauber verbucht
• Besprechung aus dem Kalender heraus mit Raum geändert. => wurde sauber verbucht
• in bestehender Besprechung aus dem Kalender heraus Raum dazu gebucht. => wurde sauber verbucht
• in bestehender Besprechung aus dem Kalender heraus Raum entfernt. => wurde sauber verbucht
• Eintrag direkt in der Reservierungs-DB erstellt. => wurde sauber verbucht
• Eintrag direkt in der Reservierungs-DB geändert. => wurde sauber verbucht
• Eintrag direkt in der Reservierungs-DB Raum geändert. => wurde sauber verbucht
• Eintrag direkt in der Reservierungs-DB Zeit geändert. => wurde sauber verbucht

Scheint also alles zu funktionieren, trotz Modified-Datum in der Zukunft.
Hmmm... aber irgendwie habe ich ein komisches Gefühl bei der Sache.

P.S.: Von der IBM habe ich nichts mehr gehört, obwohl ich per Mail darum bat, daß ich ein Statement zum Verhalten des RnRMgr haben wollte, schade.

[eknori]

Vielen Dank erst einmnal für die Mühe, die du dir gemacht hast. Das ist mit Sicherheit wertvolles Wissen, das man sich verlinken sollte.

P.S.: Von der IBM habe ich nichts mehr gehört, obwohl ich per Mail darum bat, daß ich ein Statement zum Verhalten des RnRMgr haben wollte, schade.

Hattest du etwas anderes erwartet? Ich nicht. Für die IBM sind solche Dinge absolut nebensächlich. Das Verhalten gibt es offenbar schon seit Jahren ( works as designed ) und es hat auch offensichtlich immer funktioniert. Zumindest ist niemandem irgend etwas negativ aufgefallen. Und wenn dann irgendwann einmal wirklich ein Problem auftauchen sollte, ist immer noch Zeit, sich damit zu beschäftigen. Damit ist das Thema vom Tisch.