Domino 9 und frühere Versionen > ND6: Entwicklung

Wie "eo12345678tm"-Dateien vermeiden ?

(1/1)

datenbanken24:
Wir setzen Java-Agenten in Notes-Datenbanken ein, um z.B. Attachments aus Dokumenten zu bekommen.
Klappt alles einwandfrei, ABER...

der Befehl:

Embedded Object eo = doc.getAttachment(filename)

hinterlässt unabhängig vom Betriebssystem und unabhängig ob Client oder Server
im  Notes-Programmverzeichnis

für jeden Aufruf diese

eoXXXXXXXXtm - Dateien,

mit xxxxxxxx als fortlaufende achtstellige Nummer.

db.recycle und session reycling helfen hier nix.

Wie bekommt man diese Dateien wieder weg
bzw. Notes dazu, die von selbst wieder zu löschen ?

Gruß,
Uwe

datenbanken24:
Problem gelöst:


Man muss explizit den
FileInputStream "closen"

fis.close();

UND

das Embededobject recyclen
eo.recycle();

Dann werden die eoXXXXXXXXtm Dateien von Notes wieder automatisch entfernt.


Da man das doc im Web aus dem agentcontext ableitet und nicht aus dem db-Objekt recycelt man beim recyclen des db-Objectes NICHT automatisch das eo-Object mit. Auch das Recyclen der Session reicht hier NICHT aus.

In der Designer-Help gibt es keine Hinweise darauf, dass man das eo-Object (zumindest im Web)  explizit recyclen muss.

Marinero Atlántico:
danke für den Hinweis.

Es folgen ein paar altkluge Bemerkungen.

.close() ist definitiv kein Spass-Thema für alle Sorten von Streams und Connections (RDBMS, JMS, files, was auch immer).

Ausserdem hat das ein paar Haken.

--- Code: ---
try {
// fis öffnen

// do stuff

// wird fis geschlossen, wenn hier eine exception geworfen wird? NEIN! fis.close wird dann nicht erreicht.

fis.close();
fis = null;
} catch (ANeededException) {
 e.printStackTrace();
} finally {
 if (fis != null) {
       try {
        fis.close();
      } catch {}
 }
}

--- Ende Code ---

Die Verbindung von Exception-Catching und closen von Streams/Connections kann zu wirklich stark verschachtelten code führen, wenn man robusten code schreiben will (was Sinn macht).
Moderne Frameworks kümmern sich oft darum, was sehr gut ist.

Noch was:
Solltest du FileInputStream direkt verwenden, wrap das in einen BufferedInputStream, so nach der Art:

--- Code: ---BufferedInputStream buf = new BufferedInputStream(new FileInputStream(stuff));

--- Ende Code ---

Das bringt oft sehr merkbare Performancesteigerungen.

Gruß Axel

Navigation

[0] Themen-Index