Cache mich

Test-Driven-Development ist eine feine Sache: man schreibt einen Test, welcher einen Anwendungsfall simuliert und implementiert und testet das Interface, bis alles so sauber funktioniert, wie es das Interface verspricht.

Meine Tests laufen als Remote-Client und testen Remote-Interfaces von stateless Session Beans. Das ist zwar etwas umständlich, entspricht aber dem für die Anwendung geplanten Szenario. Es sind also keine Unit- sondern eher Integration-Tests. Mit Glassfish und Netbeans ist das einfach aufgesetzt - man muss nur appserver-rt.jar im Classpath der Tests haben und kann dann einfach InitialContext JNDI lookup() ausführen.

Implementieren von Methoden, Deployen der stateless Beans und Ausführen der Tests geht selbst auf meinem 2GB Thinkpad T60 recht zügig (natürlich läuft da auch die Informix DB noch drauf).

Etwas macht mir aber Kummer: Irgendwie passiert es immer wieder, dass der Persistence Context definitiv behauptet, es gäbe von einer Entity garantiert gar kein Exemplar mehr und dann beim persist() eine ExceptionEntityExists auslöst, weil er dann meint, den Primary Key doch schon zu kennen. Und das, obwohl unmittelbar vor dem persist() ein Query "delete from Entity" ausgeführt wurde und ein em.find() mit dem Key der neu einzufügenden Entity nichts findet.

Ich habe den Eindruck, dass durch das Deployen der zu testenden EJBs die Synchronisation der Persistence Contexts, die für jede Methode der stateless Beans (pro Transaction) erzeugt werden, mit dem 2nd Level Cache der Toplink Essentials beschädigt wird.

Ich habe in Wonseok Kim's Blog einiges zum Thema Toplink Cache gefunden.

Das Problem lässt sich nur durch Stoppen und Starten des Glassfisch beheben.

Allerdings macht mich die Idee nervös, mit solchen Effekten rechnen zu müssen, wenn in einem in Produktion laufenden Glassfish neue Versionen deployed werden. Kommt Zeit, kommt Rat!?