Domino 9 und frühere Versionen > Entwicklung

Personengebundene Profildokumente

<< < (4/4)

animate:
Meine Erfahrung mir Profildokumenten:

Sie und damit ihr Inhalt werden im RAM gespeichert, um sehr schnellen Zugriff zu ermöglichen
Ich kann nicht sagen, ob die Werte, die ich gerade auslese, aktuell sind oder alt
Aktualisierung findet nicht zwingend bei Beenden + Neustart des Clients statt
In Webanwendungen tödlich
Ich verwende sie nie wieder, lieber einfache Dokuemente

koehlerbv:
Userbezogene ProfileDocs erfüllen eigentlich genau den Zweck, den man von ihnen erwartet: Sie sind schnell (weil im RAM gechached), und da sie personenbezogen sind, sind sie immer aktuell (weil - wenn man die Userbezogenheit nicht irgendwie übel unterläuft - sie jede vom User vorgenommene Änderung eben auch im RAM wiederspiegeln). Und wenn der Client beendet wird, geht auch der Pointer zum Cache verloren. Beim Neustart werden sie bei erster Anforderung neu eingelesen !
Genau das sollte aber gar kein Problem darstellen - siehe oben.

Übel wird es hingegen bei gemeinsam verwendeten ProfileDocs. Diese sollten nur dann zum Einsatz kommen, wenn die ProfileDocs äusserst selten geändert werden (Konfigurationen zum Beispiel). Häufig schliesst aber genau diese Bedingung "selten geändert" den Einsatz von ProfileDocs aus, und der erfahrene Programmierer verwendet schnell erreichbare "normale Dokumente".

HTH,
Bernhard

PS: Wenn ich Axels Anforderungen richtig gelesen habe, sind daher persönliche ProfileDocs die richtige Lösung für sein Problem. Die NOTES.INI und dann auch noch das Splitten von Strings ist ein übles Vorgehen, unsicher dazu - und macht wegen Chaching de facto keinerlei Unterschiede.

Glombi:
Profildokument sind
- schnell da im Cache
- u.U. unbrauchbar da im Cache

Also: Diese nur verwenden, wenn deren Inhalt sich innerhalb einer Session nicht ändert.

Ich versuche mal im folgenden einige Links zu sammeln. Wenn genug da sind bzw. auch Interesse besteht, sollten wird das mal als BP zusammenstellen:

http://www-10.lotus.com/ldd/today.nsf/0/f1e0daa9317ae8a6852565560071fb87?OpenDocument
http://www.dominopower.com/issues/issue200409/00001383001.html
http://www.breakingpar.com/bkp/home.nsf/0/87256B280015193F87256D26006BA928


Bei einem meiner Kunden sind Profile Dokument verschwunden. als der Server gecrashed ist. Da diese für fortlaufende Nummern verwendet werden, war das unschön.

Andreas

Glombi:
Aus der KBASE:
Title:   
   @GetProfileField Function Pulls From Database Cache Over the Web
Product:   Lotus Domino  >  Lotus Domino Server  >  Version 5.x
Platform(s):   Platform Independent
Date:   13.09.2004
Doc Number:   1095930


This document is based on the following Software Problem Report (SPR):
About SPRs
SPR Number   SPR Status   SPR Fixed Release
HMEA4HPUGD   Under Investigation   Not Applicable
Problem
The @GetProfileField function is designed to retrieve a field from a profile document and cache the field value for the remainder of the session.

However, the @GetProfileField function has the capability of pulling information from cache and never actually updates current cached information, prevent current information from getting to the profile document.  The servers shows that the agent ran, but the information is pulled from the database cache.



Solution
This issue has been reported to Lotus Quality Engineering.  As a workaround, instead of modifying the Profile Document's item values, try deleting the profile document and recreating it via LotusScript.   For example:

set doc = db.GetProfileDocument( profilename$, username$ )
call doc.remove( true )
set doc = db.GetProfileDocument( profilename$, username$ )
doc.fieldname = "new value"
call doc.save( false, false )

Marinero Atlántico:
unsere bisherigen Ergebnisse sind stabil. D.h. für diesen Verwendungszweck (PersonenProfile strikt: reinschreiben aus LS -> auslesen mit Formelsprachencode, der den LS-Script Agenten vorher gestartet hat (alles ein Prozess) scheint es wirklich stabil zu funktionieren).
Nun sind caches in verteilten Umgebungen wirklich nicht trivial zu implementieren.

Navigation

[0] Themen-Index

[*] Vorherige Sete