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

@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

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

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

@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

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

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.