Die beste Vorgehensweise ist alle Domino-Objekte während des Umfangs zu recyceln, in dem sie erstellt werden. Beim Recycling eines Objekts werden jedoch automatisch alle Objekte "darunter" recycelt. Daher können Sie in Ihrer Beispielmethode nicht wDb recyceln, da dies dazu führen würde, dass auch wDoc recycelt wird, sodass Sie ein wiederverwendetes Dokument-Handle zurückgeben.
Wenn Sie also sicherstellen möchten, dass kein Speicher ausgelaufen ist, empfiehlt es sich, die Objekte in umgekehrter Reihenfolge zu rezyklieren (z. B. zuerst das Dokument, dann die Ansicht und dann die Datenbank). Dies erfordert die Strukturierung Ihrer Methoden, so dass Sie alles tun, was Sie benötigen, um mit einem Domino-Objekt innerhalb welche Methode erhält das Handle auf es.
Zum Beispiel nehme ich an, der Grund, warum Sie eine Methode definiert, um ein Konfigurationsdokument zu erhalten ist, so dass Sie den Wert der Konfigurationseinstellungen daraus ziehen können. Anstatt also ein Verfahren, das Dokument zurückzukehren, vielleicht wäre es besser, eine Methode zu definieren einen Elementwert zurückzukehren:
private Object lookupItemValue(String configKey, itemName) {
Object result = null;
Database wDb = null;
View wView = null;
Document wDoc = null;
try {
Session sess = ExtLibUtil.getCurrentSession();
wDb = sess.getDatabase(sess.getServerName(), this.dbname1);
wView = wDb.getView(this.viewname1);
wDoc = wView.getDocumentByKey(configKey, true);
this.debug("Got a doc for key: [" + configKey + "]");
result = wDoc.getItemValue(itemName);
} catch (NotesException ne) {
if (this.DispLookupErrors)
ne.printStackTrace();
this.lastErrorMsg = ne.text;
this.debug(this.lastErrorMsg, "error");
} finally {
incinerate(wDoc, wView, wDb);
}
return result;
}
Es gibt ein paar Dinge, über die über diesem Verdienst einer Erklärung:
- Normalerweise in Java deklarieren wir Variablen bei der ersten Verwendung, nicht den Stil des Inhaltsverzeichnisses. Aber mit Domino-Objekten ist es am besten, zu TOC zurückzukehren, so dass, egal ob eine Ausnahme ausgelöst wurde oder nicht, wir versuchen können, sie wiederzuverwenden, wenn wir fertig sind ... daher die Verwendung von schließlich.
- Das Rückgabeobjekt (das ein Elementwert sein sollte, nicht das Dokument selbst) wird ebenfalls im Inhaltsverzeichnis deklariert, sodass wir dieses Objekt am Ende der Methode zurückgeben können - auch hier, ob eine Ausnahme aufgetreten ist es gab eine Ausnahme, vermutlich ist es immer noch null).
- In diesem Beispiel wird eine Dienstprogrammmethode aufgerufen, mit der alle Domino-Objekte zum Recyceln an einen einzelnen Methodenaufruf übergeben werden können.
Hier ist der Code dieser Utility-Methode:
private void incinerate(Object... dominoObjects) {
for (Object dominoObject : dominoObjects) {
if (null != dominoObject) {
if (dominoObject instanceof Base) {
try {
((Base)dominoObject).recycle();
} catch (NotesException recycleSucks) {
// optionally log exception
}
}
}
}
}
Es ist privat, wie ich gehe davon aus, Sie werden es nur in der gleichen Bohne definieren, aber in letzter Zeit neige ich dazu, diese als öffentlich definieren statische Methode einer Util-Klasse, die es mir erlaubt, von überall her dem gleichen Muster zu folgen.
Eine letzte Anmerkung: Wenn Sie zahlreiche Elementwerte aus einem Konfigurationsdokument abrufen, wäre es natürlich teuer, eine neue Datenbank-, Ansichts- und Dokumentkennung für jeden Elementwert einzurichten, den Sie zurückgeben möchten.Daher würde ich empfehlen, diese Methode zu überschreiben, um eine Liste String > (oder String []) von Elementnamen zu akzeptieren und eine Map < String, Objekt > der resultierenden Werte zurückzugeben. Auf diese Weise können Sie ein einziges Handle für die Datenbank erstellen, anzeigen und dokumentieren, alle benötigten Werte abrufen und die Domino-Objekte anschließend wiederverwenden, bevor Sie die zurückgegebenen Elementwerte tatsächlich verwenden.
Ein weiterer Kommentar neben Tims ausgezeichneter Antwort: Ein (viel) schnellerer Weg, ein bestimmtes Dokument abzurufen, ist die Verwendung eines Aufrufs db.getDocumentByUNID(). Wenn Sie also dasselbe Dokument mehrmals abrufen müssen, können Sie es beim ersten Aufruf aus der Ansicht abrufen und seine UNID in einer privaten Variablen speichern. Bei subsuquen Calls können Sie dann diese UNID verwenden, um sie abzurufen. –
@Mark: Ich habe bereits Caching der Daten in entsprechenden Scope-Variablen implementiert, sobald das Dokument gelesen wird, so dass es selten die Notwendigkeit gibt, das Dokument erneut zu lesen, bis die Bereichsvariablen verschwunden sind ... In einigen Fällen die Informationen in der Die Bereichsvariable enthält die UNID, sodass der Zugriff auf das Dokument so schnell wie möglich erfolgt./Newbs – Newbs