Bug bei NotesDocumentCollection

[Reiner2005]

Hallo,
ich glaube, ich habe einen Fehler bei NotesDocumentCollection gefunden.

Ich habe eine Funktion geschrieben, welche mir eine NotesDocumentCollection zurückgibt. Wenn ich diese Funktion auf der aktuellen Datenbank (CurrenDatabase) laufen lasse, funktioniert alles prima. Wenn ich allerdings eine andere Datenbank (z.B. demo77) angebe so klappt zwar der Ablauf innerhalb der Funktion, aber ich bekomme 'nothing' zurück.

Das heist im untigen Bespiel gibt die Funktion ordnungsgemäß "result.count=77" in der Message-Box aus - liefert aber 'Nothing' als Rückgabewert. (Wie gesagt, auf der aktuellen Datenbank, bekomme kein Nothing).

Hat jemand schon mal mit diesem Bug zu tun gehabt und weiß vieleicht sogar eine Möglichkeit das Problem zu umgehen?

Gruß,
Reiner


Function getCollection() As NotesDocumentCollection
   Dim result As notesDocumentCollection   
   Dim db As notesdatabase
   Dim server As String
   Dim file As String
   Dim searchstring As String
   
   Dim session As New notessession
   
   server = "notes1/org"
   file = "demo\demo77.nsf"
   Set db = session.GetDatabase( server, file, False )
   If db Is Nothing Then
      Msgbox( "db is nothing" )
   End If
   
   searchstring = "form=""KUNDENDDATEN"""
   Set result = db.search( searchstring, Nothing, 0 )
   
   If result Is Nothing Then
      Msgbox( "result is nothing " )
   Else       
      Msgbox( "result.count=" & result.count )
   End If
   
   Set getCollection = result
End Function

[koehlerbv]

Das ist wahrlich kein Bug. Wenn Du auf (Tochter-)Objekte in anderen Objekten zugreifst, musst Du auch zwischen den jeweils übergeordneten Objekten eine Beziehung herstellen.

Funktionieren würde also:
Function getCollection (dbTarget as NotesDatabase) As NotesDocumentCollection

dbTarget muss dann auch als Objekt im aufrufenden Modul bekannt sein. Gleiches gilt für views, documents etc., wenn diese über eine NotesDatabase in einem untergeordneten Modul instantiiert werden.

HTH,
Bernhard

[Marinero Atlántico]

Bernhard. Das verstehe ich nicht.
db ist eine lokale Variable.
Es steht für einen Pointer auf die Datenbank auf den entfernten Server.
Diese lokale Variable wird korrekt instantiiert.
Von diesem Objekt wird ein db.Search() abgesetzt und zwar korrekt.
Ob diese Variable an die Methode per Parameter übergeben wird oder in der Methode instantiiert wird, ist aus meinem Verständnis völlig egal.
Ich hab sowieso das "extrem effiziente" dbsearch nie gemocht.

Axel

[Semeaphoros]

Das ist tatsächlich noch nicht vollständig erklärt, auch wenn Bernhard den Grund angegeben hat ....

db ist lokale Variable der Subroutine, das ist richtig. Da es lokale Variable wird, wird sie beim Return aus der Subroutine dereferenziert und damit wird die DB auf dem Server automatisch geschlossen. Dabei werden aber auch alle von der DB abhängigen Objekte - in diesem Falle die DocCollection - dereferenziert. Das ist absolut korrekt.

Dass das bei der CurrentDB nicht passiert, unabhängig davon, ob sie lokal oder auf dem Server sitzt, ist auch klar, denn solange der Code läuft, ist die CurrentDB zwangsweise offen und wird nicht dereferenziert, selbst wenn die Variable im Code dereferenziert wird. Wird quasi vom System offen gehalten. Aehnliche Erscheinungen kann man haben, wenn man solchen Code im Debugger verfolgt und die fragliche DB dort geöffnet hat.

[Marinero Atlántico]

  jetzt hab ich was gelernt.
Hab das aber auch erst nicht richtig gelesen:
Und zwar den entscheidenden Satz:

Das heist im untigen Bespiel gibt die Funktion ordnungsgemäß "result.count=77" in der Message-Box aus - liefert aber 'Nothing' als Rückgabewert.

Ein möglicher Workaround - ohne es probiert zu haben - besteht vermutlich darin, dass man db in den Declarations als global deklariert. Wie Bernhard schon angedeutet hat.

Das heist im untigen Bespiel gibt die Funktion ordnungsgemäß "result.count=77" in der Message-Box aus - liefert aber 'Nothing' als Rückgabewert.

Sehr interessant. Mir noch nicht aufgefallen. Diese Objekte auf anderen Datenbanken sind ja remote connections, die wohl logischerweise geschlossen werden müssen, sobald das Objekt, dass diese hält, dereferenziert wird. Ausserdem dürfte die Anzahl dieser Remote Connections insgesamt begrenzt sein, so dass es gut ist, dass die nur für einen begrenzten Zeitraum gehalten werden.
Ähnliche Logik wie in EJB btw.

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

[Reiner2005]

Hallo,
danke Bernhard (koehlerbv), die von Dir angegebene Lösung funktioniert. Mit diesem Tipp konnte ich mein Problem lösen. Danke auch an Semeaphoros, durch die zusätzliche Erklärung ist mir nun klar was da im Hintergrund bei Notes abläuft.

Ihr habt mir sehr geholfen, habe zwischenzeitlich schon ziemlich auf Notes geschimpft. Ich bin zwar immer noch der Meinung, dass Notes etwas übereifrig ist beim Dereferenzieren. Eine Referenz sollte erst gelöscht werden wenn auch die abhängigen Referenzen nicht mehr gebraucht werden. So arbeiten zumindest etliche andere Garbage-Collectoren (z.B. Java). Wenn man aber um die Vorgehensweise bei Notes Bescheid weis - so wie nun auch ich - so kann man damit arbeiten.

Meine Lösung sieht übrigens so aus:
Ich habe einfach eine zusätzliche Zeile in die Funktion eingefügt.

set dbGlobalTrick = db

wobei dbGlobalTrick, wie schon der Name sagt, global in der Skriptbibliothek deklariert ist und woanders nicht genutzt wird.


Danke und Grüße,
Reiner
 

[Semeaphoros]

Hmm - Delphi dereferenziert abhängige Objekte (von denen es das weiss) ebenfalls, wenn das Hauptobjekt dereferenziert wird. Java tikt da natürlich anders, was ich irgendwo nachvollziehen kann. Beide Varianten haben ein eigenes Set von Vor- und Nachteilen --- wie oft vergisst man, ein abhängiges Objekt explizit zu dereferenzieren? Und schon ist das "Memory-Bloating" perfekt.

Im Sinne der Pflegbarkeit des Codes hätte ich jetzt keine globale Variable gesetzt, sondern die Sache über einen Parameter, wie von Bernhard vorgeschlagen, gelöst.

[Marinero Atlántico]

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.

wie raffiniert es ist, wissen wir nicht, da es nicht dokumentiert ist.

--- wie oft vergisst man, ein abhängiges Objekt explizit zu dereferenzieren? Und schon ist das "Memory-Bloating" perfekt.

NO FAIR.   
NO FAIR.   
NO FAIR.   
USTEDES SON UNOS MENTIROSOS. 

In Java werden auch abhängige Objekte eligible for garbage collection, wenn das übergeordnete Objekt genullt wird. Alles andere wäre auch Schwachsinn, da man ja keinen Pfad mehr hat, mit dem man auf das abhängige Objekt navigieren kann.
Wenn ich sowas habe:

Code

class Person {

 String name;

public static void main (String args[]) {
  Person person = new Person();
  person.name = "jupp";
  person = null;
  // dann ist hier person.name = "jupp" auch eligible for garbage collection
/*
 ansonsten müsste ich ja immer so machen: 
  person.name = null;
  person = null; 
Aber so ist es nicht. Abhängige Objekte auf die es keinen Zugriffspfad mehr gibt werden mit garbage-collected. 
*/
}

Was nur in den Beispiel passiert. Über die Initialisierung des Rückgabewertes:

Code

Set getCollection = result

zeigt eine weitere Variable auf das Objekt und die ist als Rückgabewert der Funktion gesetzt.
Warum die bei der Rückgabe auf Nothing gesetzt wird, finde ich nicht einleuchtend. Wird das nicht by-reference zurückgeben?
In Java würde diese eine Variable auf das Objekt zeigen und es wäre somit nicht eligible for garbage Collection.
Der Rückgabewert einer Funktion gehört nach meiner Logik eindeutig in den - sagen wir - Zugriffsscope der aufrufenden Funktion.

peace

Axel

[Semeaphoros]

Gute Frage, da müsste man jetzt die Innereien wirklich kennen. Da die Datenbank beim Verlassen der Function dereferenziert wird, wird der Owner und/oder Parent der Collection dereferenziert. Ob die Collection damit noch eine "Ueberlebenschance" hat, hängt ganz vom inneren Organismus dieses Objektes ab, und Collections in Notes sind alles andere als einfache Objekte ...... somit stehen wir hier wohl aussen vor mit der Betrachtung.

[Marinero Atlántico]

yup. Ich denke, dass die Collection NotesDatabase braucht.
Was ich so beobachtet habe ist, dass NotesDatabase ein sehr teures Objekt ist, wo viel drin ist. NotesSession ist dagegen ziemlich klein. Sowas wie NotesCollection auch.
Kann man ganz gut sehen, wenn man extern mit Java drauf zugreift. Da wird ja auch nur der C-code gewrappered.

[Semeaphoros]

Deckt sich mit meinen Erfahrungen und Vermutungen

[koehlerbv]

By the way, das Thema hatten wir bereits Anfang des Jahres, und das wurde damals bereits ganz gut diskutiert:
NotesDoc als Rückgabewert einer Funktion

Ansonsten: Wenn ein gekapseltes Modul (wie eine Function) auf Basis eines übergeordneten Objekts (hier: NotesDatabase) ein abhängiges Objekt erstellt, kann es dieses nicht nur in LotusScript nicht an ein anderes Modul übergebe, insofern dort das übergeordnete Objekt nicht auch bekannt ist. Es gehen ja sonst sämtliche Bezüge zwischen den abhängigen Objekten verloren.

Ansonsten:
- Geöffnete DBs sind recht harmlos, wenn sie vom Programmierer geöffnet, aber nicht wieder von ihm explizit geschlossen werden. Ist das Modul terminiert, ist auch die DB wieder "befreit". Das ist aber natürlich extrem schlechter Stil und sollte immer unterbleiben.
- Wenn das Objekt "NotesDatabase" nicht noch woanders gebraucht wird, würde ich das unter keinen Umständen global deklarieren und instanziieren, sondern nur im betreffenden aufrufen Modul und dann by reference an das untergeordnete Modul übergeben (wie oben beschrieben). Wird das aufrufende Modul terminiert, dann verabschiedet sich damit auch das Objekt "NotesDatabase" - durchaus bequem und sehr sicher.

HTH,
Bernhard