Wie "eo12345678tm"-Dateien vermeiden ?

[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 {}
 }
}

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));

Das bringt oft sehr merkbare Performancesteigerungen.

Gruß Axel