Caching in DIIOP Sesison

[Kolja]

Hallo!

Ich arbeite momentan an einer J2EE Applikation, die unter Anderem über DIIOP auf eine Domino Datenbank zugreift.
Dazu wird eine Session geöffnet, es werden Dokumente geladen (meßtens über db.FTSearch) und es werden Änderungen an den Dokumenten vorgenommen.
Nun muss ich leider feststellen, daß wenn ich mit einer bestehenden Session ein Dokument lade, die Inhalte der Felder nicht immer den tatsächlich aktuellen Werten in der Datenbank entsprechen.
Wenn ich also während des Lifecycles der DIIOP Session an bereits geladenen Dokumenten Änderungen vornehme (z.B. vom Notes Client aus), enthält das Dokument j2ee-seitig auch nach erneutem Laden noch die alten Werte.

Momentan schließe ich also immer wenn ich möglichst verlässlich aktuelle Daten brauche die Session, rufe session.recycle() auf und baue eine komplett neue Verbindung auf.
Das funktioniert, stellt mich aber nicht wirklich zufrieden, weil dieser Reconnect an einigen Stellen über 50% der Gesamtzeit der gewünschten Operation einnimmt.

Deshalb die Frage:
Ich vermute, daß bereits geladene Dokumente im Rahmen der Session gecached werden, ist das Richtig?
Wenn dem so ist, gibt es eine Möglichkeit, diesen Cache zu umgehen und das Dokument tatsächlich frisch aus der Datenbank zu holen?
Bin für jeden Tip dankbar.

Gruß

Kolja

[MadMetzger]

Ich kenn mich jetzt zwar nicht mit DIIOP und Co aus. Aber meine Idee wäre es, das Ausführen der Änderungen nebenläufig zu machen und es evtl über ein Active Object durchführen. Damit würdest du Wartezeit für den Benutzer verkürzen, nur hättest du dann halt die Änderungen nicht sofort sondern erst dann, wenn das Active Object dazu gekommen ist.

[m3]

FTSearch liefert laut Designer-Hilfe eine DocumentCollection zurück. AFAK und IIRC, diese Collection buffert. Ich würde es mal probieren, die gesuchten Dokumente über eine View zu holen. Ich denke, dann bekommst Du immer das aktuelle.

Oder Du holst Dir aus dem Dokument die UNID und holst über die NotesDatabase Methode "getDocumentByUNID" das aktuelle Dokument aus der DB.

[flaite]

Ja. Die werden in Sessions gecached. Hast du dir mal versucht, ein frisches zu holen, z.B. über db.getDocumentByUnid. Ich weiss aber nicht, ob das funktioniert Das sollte funktionieren, wird aber deine Anwendung sicher nicht beschleunigen.
Hälst Du die Session über mehrere Request/Response Zyklen auf der J2EE Seite offen (etwa durch caching derselben in HttpSession oder einer Statefull Session Bean?). Halte ich für ein bischen problematisch, weil die Session ja irgendwann sowieso time-outet und das bestimmt auch nicht so gut skalliert bei vielen Usern.
DIIOP ist sowieso langsam. Vielleicht kannst du den Domino Server auf eine andere physische Kiste legen, du installierst einen Notes Client auf der Kiste des J2EE Servers und benutzt local statt DIIOP.  Das könnte sogar schneller sein.

@Markus: Eigenes Thread Pooling ist in J2EE eigentlich verboten (unten auf dieser Seite: http://java.sys-con.com/read/83057.htm). Ich habs zwar often gesehen, mich macht das aber nervös.

JMS/Message Driven Beans ist vielleicht wirklich auch eine Option, um die Anwendung responsiver zu machen. Ist zwar auch ein Faß aber ein paar Überlegungen wird. Sowas wird in dem oben verlinkten Artikel besprochen.

Gruß Axel

[Ralf_M_Petter]

Kann Axel nur Recht geben. Für performancekritische Sachen ist DIIOP zu vergessen. Würde ebenfalls lokalen Zugriff verwenden. Ich habe mit Notes 6 performancetests gemacht und die performance vom lokalen Zugriff war bei meiner Testanwendung um den Faktor 3 besser.

Mit einem Hotfix der IBM für Websphere Express haben wir sogar vermieden die Threadinitialisierung bei jedem Seitenaufruf zu machen. Was die performance nocheinmal extrem gesteigert hat.

Grüße

Ralf