Ge-chachte Profildokumente

[ata]

Hallole @All

ich habe eine Datenbank, in der Dokumente in der Reihenfolge ihrer Erstellung nummeriert werden. Diese Nummer pflege ich in einem Profildokument. Die Nummer wird ausgelesen in das Dokument übernommen und im Profil um eins erhöht. Das funktioniert prächtig, wenn man alleine mit der DB arbeitet... aber

... wenn mehrere User auf dem Server Dokumente ertellen kommt es zu doppelten Nummern, und dabei liegen teilweise 10 Minuten zwischen solchen Vorgängen.

Profildokumente werden beim Öffnen der DB in den Cache geschrieben und liegen damit permanent vor - daher das Problem - so weit so gut.

Meine Frage: gibt es eine Möglichkeit das Profildokument in anderen Sessions der User zu atualisieren - asonsten gehe ich den Weg über ein reguläres NotesDocument, daß kann ich so aktuell halten, wie es Notes eben zulässt...

Vielen Dank vorab für euere Beiträge...

ata

[harkpabst_meliantrop]

Wie wäre es mit einer Ansicht zum ermitteln der letzten vergebenen Nummer? Ist natürlich bei sehr vielen (und am Ende noch unterschiedlichen) Dokumenten eventuell auch nicht besonders schnell, aber mit einen View Refresh kriegt man zumindest keine Cache-Probleme...

[ata]

@harkpapst_meliantrop

... wie du schon erwähnst, je größer die DB wird, je mehr Dokumente in der DB sind, um so langsamer wird diese Art der Nummernvergabe - zudem bläht sich der Index immer größer auf...

Im Augenblick löse ich das eben über eine Ansicht, in der nur das NotesDocument erscheint...
Mit einem DBLookup lese ich das Dokument aus...
So lese ich auch die DocUNID des Dokumentes aus...
Mit @SetDocField setzte ich dann den neuen Wert...

Der Weg funktioniert, da ich im DBLookup "NoCache" mitgeben kann...

Dennoch würde mich eben interessieren, ob es eine Möglichkeit gibt ein Profildokument in allen sessions aktuell zu haten...

ata

[Rob Green]

schon mal daran gedacht, die aufsteigende Nummer in ein Textfile zu schreiben und auszulesen, das auf dem Server liegt. Dazu muß ein runonserver Agent das Textfile anpacken. Vorteil sollte sein, daß das OS konkurrierende Zugriffe auf die Textdatei selbständig regelt. Obwohlich ich wirklich nicht 100% weiß, was passiert, wenn parallel gleichzeitig 2 Notesprozesse (die 2 User unabhängig angestoßen haben) auf die Textdatei zugreifen wollen. Ob dann der eine Notesprozess vom OS netterweise angewiesen zu warten, insofern Notes warten überhaupt kennt.

Weiß jemand mehr dazu, ob das klappen könnte ohne Probs?
Also zur Wiederholung: Notes schreibt Nummer in Textfile, somit gibt es keine doppelten Nummern mehr, da das OS auf keinen Fall parallele Zugriffe auf das Textfile zuläßt. Reihenfolge ist immer: im PostSave wird letzte Nummer aus Textfile gelesen, dann im Textfile um +1 und zum Schluß im Notesdoc um +1 eines erhöht.

[ata]

@Rob

... das wäre natürlich auch noch ein Weg, an den habe ich noch nicht gedacht - ich danke dir.

Ich hatte noch den Gedanken ein temporäres Dokument zu erstellen, das als Beleg dient, daß die Nummernvergabe in Verwendung ist - gibt es das Dokument, ist die Nummernvergabe belegt - nach der Nummernvergabe wird das Dokument wieder gelöscht - so was wie ein Sperrdokument...

ata

[Rob Green]

ja, aber da entstehen eben immer wieder Race Conditions, so daß Du nie ausschließen kannst, daß nicht doch mal eine Nummer doppelt vergeben wird. Wir hatten das mal in unserer Fa. ausführlich getestet und nie ein zuverlässiges Verfahren gefunden, auch die Spezialisten von Notes/USA nicht im Rahmen von Notes selbst. Man benötigt schlicht ein externes Nadelöhr. Natürlich könnte das auch echtes RDBMS sein.

Wobei mir jetzt noch einfällt, daß es möglich sein müßte, einen Task im RAM vorzuhalten, der einmal vom Server geladen wird und danach solche Anfragen bedient. Also i.S.e. eines JSP-Ansatzes. Nur wie genau?

[harkpabst_meliantrop]

Im Augenblick löse ich das eben über eine Ansicht, in der nur das NotesDocument erscheint...

Eigentlich ja bereits eine zärtliche Vergewaltigung des Konzepts von Profildokumenten, die ja in keiner Ansicht auftauchen sollen ...

Mit einem DBLookup lese ich das Dokument aus...
So lese ich auch die DocUNID des Dokumentes aus...
Mit @SetDocField setzte ich dann den neuen Wert...

Der Weg funktioniert, da ich im DBLookup "NoCache" mitgeben kann...

Das Keyword [NoCache] umgeht also scheinbar nur das Caching des Clients (für den einzelnen Benutzer erfolg der Zugriff tatsächlich immer neu), fällt aber auf das Caching des Servers (das Profildokument wird nicht wirklich in die DB geschrieben) trotzdem herein? Lustig. Ich verstehe schon, warum Profildokumente bei meinen Kollegen immer schon juckenden Hautauschlag verursacht haben ...

Dennoch würde mich eben interessieren, ob es eine Möglichkeit gibt ein Profildokument in allen sessions aktuell zu haten...

Zumindest die Dokumentation gibt einem da ja keinerlei Hinweise an die Hand. Aber wenn schon der Lookup mit NoCache nicht wirklich ungecached ist, kann ich kaum an eine Lösung glauben.

Aber auch mit einem herkömmlichen Dokument hast du ja immer noch das Problem mit potenziellen Speicherkonflikten. Da müsstest du doch eigentlich immer noch ein Locking für das Dokument implementieren.

Bei Zugriff ausschließlich über LotusScript könnte auch das ...

Semaphore service
To support thread-safe code, we have introduced semaphore services. This service is available through the LSX Toolkit.

... vielleicht helfen. Aber wer kann damit schon umgehen? Ich (noch) nicht ...

[harkpabst_meliantrop]

Ups, der Zug der Zeit hat mein Posting wohl stellenweise überrollt ...

[ata]

@harkpapst_meliantrop

... danke dir erst mal. Das mit dem Locking ging mir auch durch den Kopf. Ich werde mich auch nach dem LSX kundig machen, ich höre davon das erste Mal...

@rob

... die Thematik scheint tiefer zu sitzen als befürchtet. Vielleicht tuts auch ein Agent, der doppelte Dokumente filtert und eine neue Nummer verpasst. Der Author des Dokumentes wird davon verständigt... eventuell weniger Aufwand

ata

[Rob Green]

jo, im nachhinein ist das sicher ganz easy, doppelte Nummern zu bereinigen. Dann braucht man sich nicht relativ gesehen zu verrenken.

semaphore? Damit wird sicher die Möglichkeit von echtem  Multithreading in Notes zb im Rahmen von LS Agents gemeint sein, oder? Da gab es doch letztens Artikel irgendwo auf searchdomino und ldd dazu!?

[harkpabst_meliantrop]

Aber das ...

Dazu muß ein runonserver Agent das Textfile anpacken. Vorteil sollte sein, daß das OS konkurrierende Zugriffe auf die Textdatei selbständig regelt. Obwohlich ich wirklich nicht 100% weiß, was passiert, wenn parallel gleichzeitig 2 Notesprozesse (die 2 User unabhängig angestoßen haben) auf die Textdatei zugreifen wollen.

... ist ja mal eine wirklich interessane Idee. LS lockt das Dokument im Zugriff ja selbst und zumindest nach meinen lokal durchgeführten Tests gilt dieser Lock offenbar nicht etwa nur für die NotesSession, sondern wird tatsächlich über das OS abgewickelt. Solange ein Scritp eine Datei im Zugriff und noch nicht wieder freigegeben hat, kann man sie auch mit anderen Programmen nicht verändern.

Da das mit Notes und Warten ja immer so eine Sache ist (wie du ja sehr plastisch beschrieben hast ) sehe ich das größte Problem darin, was man macht, wenn ein Script eben nicht auf das gerade von einem anderen Script gesperrte Dokument zugreifen kann. Es gibt ja diese seltsamen Sleep-Funktion (mit garantierter CPU-Auslastung), aber endgültig sicherstellen, dass ein Script wirklich mal "an die Reihe kommt" kann man da vermutlich nicht. Die Anwender wären vermutlich nicht erbaut, wenn man ihnen eine Meldung präsentieren würde wie:
"Ihr Dokument kann im Moment nicht gespeichert werden, probieren Sie es doch später noch einmal ...".

[harkpabst_meliantrop]

semaphore? Damit wird sicher die Möglichkeit von echtem  Multithreading in Notes zb im Rahmen von LS Agents gemeint sein, oder?

Genau.

Da gab es doch letztens Artikel irgendwo auf searchdomino und ldd dazu!?

Wenn ich nur etwas Zeit hätte (einfach weniger posten ) würde ich mich da auch mal sehr gerne drum kümmern ... Notes-Gefruckel wird langsam doch zu richtigem Programmieren ...

[Rob Green]

jo, das müßte man über mehrere, abgefeurte Agents parallel mal antesten, was passiert, wenn File von Prozess 1 in Zugriff ist. Entweder knallt es bei den anderen oder Notes wartet.

[ata]

... das werde ich mal testen, bloß wirds damit heute voraussichtlich nichts mehr...

ata