Domino 9 und frühere Versionen > Entwicklung

Ge-chachte Profildokumente

<< < (2/3) > >>

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:

--- Zitat von: ata am 25.10.02 - 12:08:59 ---Im Augenblick löse ich das eben über eine Ansicht, in der nur das NotesDocument erscheint...
--- Ende Zitat ---
Eigentlich ja bereits eine zärtliche Vergewaltigung des Konzepts von Profildokumenten, die ja in keiner Ansicht auftauchen sollen ... ;)


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


--- Zitat ---Dennoch würde mich eben interessieren, ob es eine Möglichkeit gibt ein Profildokument in allen sessions aktuell zu haten...
--- Ende Zitat ---
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 ...

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

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete