Domino 9 und frühere Versionen > Entwicklung

Bug bei NotesDocumentCollection

<< < (2/4) > >>

Semeaphoros:
Das hat nix mit der remote connection zu tun, das gleiche passiert lokal, wenn es nicht die CurrentDatabase ist oder die betreffende Datenbank noch woanders geöffnet wurde (und bleibt). Letzerer Fall kann natürlich ganz schön Probleme bereiten, wenn man sich nicht bewusst ist, wo man sie offen gehalten hat.

koehlerbv:
In meinem Beispiel braucht man die NotesDatabase nicht global zu definieren - sie wird im aufrufenden Modul deklariert und instantiiert und dem untergeordneten Modul by reference übergeben und steht damit in beiden Modulen zur Verfügung, Axel.

Bernhard

Semeaphoros:
Jo, so ist es, global definieren wäre eine Alternative, der springende Punkt ist der, dass die DB sowohl im aufrufenden wie im aufgerufenen Zweig offen sein muss. Wie das erreicht wird, ist technisch Nebensache (aber nicht unbedingt, wenn man an Uebersichtlichkeit und Pflegbarkeit des Codes denkt)

Marinero Atlántico:
hm. Ich glaub ich hab hier einen seit 22.12.2004 offenen Call der irgendetwas damit zu tun haben könnte. Geht um eine Azubi-Gruppe, die auf dem zentralen Server angemeldet ist, aber in Filialen arbeitet und wo deshalb wilde DocLinks, die wild zwischen mit schlechten Leitungen verbundenen sehr weit entfernten Servern verlinken, nicht richtig funktionieren (die Standards alle durchprobiert: Kachel löschen, Workspace compacten, etc.).

Btw bleibe ich dabei, dass die Iris/Lotus/IBM Entwickler ein Interesse daran haben, die Anzahl der remote Connections möglichst gering zu halten, da dies auf dem Server und dem Server wirklich Ressourcen in Anspruch nehmen sollte (ist jetzt ein bischen spekulativ).  :P
Ich hab von RPC nur einen sehr blassen theoretischen Schimmer, kenne aber andere Remoting Technologien wie Sockets, RMI und EJB ein bischen besser und aus meiner Sicht müssen:
- auf dem Client eine Art -sagen wir - Endpunkt jederzeit auf Anfragen gegen genau diesen Server bereit sein
- auf dem Client bestimmte Serverdaten gecached sein
- auf dem Server ein anderer - sagen wir - Endpunkt auf Anfragen von diesem Client warten (also für alles andere blockiert sein).

Semeaphoros:
Also, Doclinks, die tatsächlich gelegentlich problematisch sein können, haben damit direkt nichts zu tun, ich denke mal, dass die Entwickler von Iris wissen, wie man eine DB offen behält.

Der Rest ist wirklich spekulativ und wenn man mal ein wenig beobachtet hat (über die API), wann eine Datenbank geöffnet wird, dann bin ich mir nicht ganz so sicher, ob die von Dir beschriebene Strategie auch diejenige von Iris gewesen ist. Da Notes sessionless arbeitet, kann der Server im Prinzip einen "Datenbanksocket" jederzeit serverseitig wieder schliessen und bei einer neuen Client-Anfrage einen "reopen" machen, damit lässt sich das Ressourcenproblem rein von der Serverseite her problemlos kontrollieren. Es macht jedenfalls einen sehr raffinierten Eindruck, und das sind Innereien, die nicht dokumentiert sind.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete