Eine interessante Sache, die ein Eindruck von der Änderung im Java EE Bereich bringt, ist die Evolution des Verständnisses von Singletons.
Ursprünglich war es ja ein Pattern, dass in dem guten, alten Design Patterns Buch veröffentlicht wurde. Damals war es eine sinnvolle Möglichkeit, um eben nur einen Instanz von einem Objekt zu haben. Später gab es dann die Probleme in nebenläufigen Umgebungen, wo die Implementierung des Patterns nicht trivial wird, wenn man wirklich garantiert nur eine Instanz erzeugen will.
Bei EJB wurden die für Singletons notwendigen statischen Variablen verboten, was dazu führt, dass man eigentlich keine Singletons bauen kann. Allerdings geht es vor allem darum, dass man im Cluster eben nicht garantieren kann, dass es nur eine Instanz des Singletons gibt. Ob das nun wirklich ein Problem ist, sei mal dahingestellt.
Gleichzeitig änderte EJB das Programmiermodell in die Richtung, dass die Beans sich nicht mehr mit Nebenläufigkeit beschäftigen müssen: Es gibt einen Pool von Instanzen, jeder Thread bekommt eine und das war's. Im Prinzip ist das eine gute Idee, weil es den Entwickler entlastet und gleichzeitig die Anzahl der neu zu instanziierenden Klassen gering hält. Auf der anderen Seite ist es unflexibel: Man kann dies Verhalten nicht ausschalten. Außerdem ist es ausgesprochen fraglich, ob es sinnvoll ist. Bei Stateless Session Beans gibt es keinen State - warum sollte die Bean nicht Thread-Safe sein? Wo sind die Ressourcen, bei denen es Konflikte geben kann? Bei Stateful gibt es einen State, aber der ist Client-abhängig und kann daher nur von einem Thread bearbeitet werden. Bleiben Entity Beans - na ja, die sind eh nicht mehr interessant in der Form, weil sie sich in EJB 3 ändern.
Und Spring? Bei Spring sind die Spring Beans per default Singletons, was eben sinnvoll ist, weil man bei Diensten, wie sie in Stateless Session Beans oder DAOs vorkommen, die Objekte als Singletons implementieren kann - sie sind fast immer automatisch thread-safe. Falls nicht, kann man Pools benutzen oder immer ein neues erzeugen lassen - nur eine Frage der Konfiguration. Wobei Pools für leichtgewichtige Objekte (dazu können Stateless Session Beans durchaus gehören) eventuell gegenüber Neuerzeugung keine Vorteile bringen.
Was bedeutet das? Nun ja, dass EJB Komponentenmodell ist möglicherweise noch weniger sinnvoll, als man glaubt. Und Spring bietet flexible Konfiguration in diesem Bereich. Außerdem werden Singletons mit Spring genauso behandelt, wie andere Spring Beans, so dass Testbarkeit nicht leidet und der Charakter einer globalen Variable nicht mehr hat. Spring bringt eben OO zurück und bietet gerade für den Aufbau von Objektnetzen viele Vorteile.... ¶ 22:48
