Domino 9 und frühere Versionen > ND8: Entwicklung

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

<< < (5/7) > >>

eknori:
IBM Reaktion


--- Zitat ---Forwarded to development.
--- Ende Zitat ---

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.


--- Zitat ---...
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.
...
--- Ende Zitat ---

... 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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete