2 Kaimane des selben Tümpels: recyle() und NotesStream.close

[flaite]

Hi,

es gab bzgl. Java in Notes nun 2 Postings, in dem Mitglieder dieses Clubs Probleme mit dem Verständnis des Einsatzes von .recycle() hatten.
Ich hab nun bei einer Art code review eines problematischen Projekts bei einem Kunden gelernt, dass NotesStream zu ganz ähnlichen Problemen führen kann.

Java besitzt einen Garbage Collector. Dieser sorgt dafür, dass in Java erzeugte Objekte automatisch aus dem Heap Speicher entfernt werden. Garbage Collectoren sind kein Alleinstellungsmerkmal für die Programmiersprache Java. Viele Programmiersprachen benutzen Garbage Collectoren. Unter anderem auch LotusScript.

Nun sind die Klassen der Java Api für Notes als dünner Wrapper um RPC Handles implementiert. Java kann diese RPC Handles nicht wirklich verwalten. Deshalb muß man in den richtigen Momenten .recycle() aufrufen. In einem gewissen Maße enthalten die Notes Java Klassen code, der die RPC Handles managed. Wenn man recycle() auf ein Objekt aufruft, wird automatisch recycle() auf alle Objekte aufgerufen, die mit diesem Objekt erzeugt wurden.

Code

Database db = dbContext.getCurrentDatabase();
View vw = db.getView("myView"); 
DocumentCollection col = vw.getAllDocumentsByKey("myKey"); 

....
db.recycle(); 

Mit db.recycle() sorgt die API dafür, dass recycle() auf alle Objekte aufgerufen wird, die mit dem db Objekt erzeugt wurden (und zwar rekursiv, d.h. auch Objekte, die aus dem DocumentCollection Objekt erzeugt wurden, das aus der View erzeugt wurde, die aus dem Database Objekt erzeugt wurden, auf das recycle() aufgerufen wird.
Noch besser: Am Ende eines Notes Java Agenten wird recycle automatisch auf die session und den dbContext aufgerufen (oder so ähnlich).

Lange Rede kurzer Sinn: Für RPC Handles sorgt die Notes Java API für eine gewisse aber nicht vollständige Garbage Collection.

NUN kennt die LotusScript NotesStream Klasse eine close() Methode. Die Streams enthalten Referenzen auf Betriebssystemressourcen, die man mittels close() auch selber freigeben kann. In der Lotus Notes Doku steht, dass man die Methode besser aufruft, wenn man den Stream nicht mehr benötigt. Lotus Script sorgt aber dafür, dass die entsprechenden Betriebssystem-Ressourcen aufgeräumt werden, wenn der entsprechende Code Block, in der Streams instantiiert wurden, terminiert. Das funktioniert aber auch nicht immer. Die Stream-Handles sind nämlich begrenzt. Ich hab letztens festgestellt, dass es zu seltsamen Effekten kommen kann, wenn in einer Schleife viele Streams geöffnet werden, der Entwickler sich aber darauf verläßt, dass die LotusScript Implementierung die Streams ordnungsgemäß aufgeräumt werden. Insbesondere in Schleifen ruft man besser close() auf, weil die automatische Freigabe nach Beendigung der Schleife zu spät sein kann. Und zwar dann, wenn in einer Schleife viele Streams geöffnet werden.

Beide Probleme sind sehr verwandt.
Die Nots RPC Handles sind für die Java API für Notes eine externe Ressource. In der Implementierung der API existiert eine gewisse Unterstützung zur Verwaltung der handles. Die ist aber nicht immer ausreichend.
Die StreamHandles sind für LotusScript eine exxterne Ressource. In der Implentierung der API existiert eine gewisse Unterstützung zur Verwaltung der handles. Das ist aber nicht immer ausreichend.