Bitte wählen!
Am Sonntag ist Bundestagswahl. Ich möchte alle Leser dieses Blogs darum bitten, an der Wahl teilzunehmen und dabei eine demokratische Partei - also nicht NPD - zu wählen.
Und an dieser Stelle noch ein Hinweis an die NPD-Wähler unter den Lesern: Sie sind hier nicht erwünscht. Ich möchte nicht, dass die Ergebnisse meiner Arbeit von Nazis genutzt werden. Bitte bestellen Sie den Blog ab. Danke.
Event: Leichtgewichtige JEE Entwicklung mit dem Spring Framework
SpringSource und OPITZ CONSULTING zeigen auf unsere gemeinsamen
Veranstaltung „Moderne Enterprise-Java-Entwicklung mit dem Spring
Framework“ welche Vorteile die Entwicklung mit Spring bei
Individualsoftware bringt. Individualsoftware unterstützt komplexe
Prozesse optimal und lässt sich so flexibel anpassen, dass sie den
ständigen Änderungen im Geschäft gewachsen ist. Jedoch verbindet man
Entwicklung und Betrieb individueller Unternehmensanwendungen oft mit
drei Eigenschaften: teuer, riskant und aufwändig. Dass es mit den
richtigen Werkzeugen und Methoden auch anders gehen kann, möchten wir
Ihnen in dieser Vortragsreihe beweisen.
Termine:
23.9.2009
Frankfurt12.10.2009
Hamburg13.10.2009
München14.10.2009
Köln9.11.2009
Zürich Agenda
10:00 Uhr Softwareprojekte in wirtschaftlich schweren Zeiten
- Chancen und Risiken
- Bedeutung von Vorgehen und Technik
Referent: OPITZ CONSULTING
10:25 Uhr Effizienz durch moderne Entwicklungsverfahren
- Spring als Grundlage moderner Architekturen
- Qualität und Wartbarkeit durch Testautomatisierung
- Effizienz durch Vermeidung nichtdifferenzierender Entwicklung
Referent: OPITZ CONSULTING
11:15 Uhr Integration statt Neuentwicklung
- Spring als Integrationsplattform
- Effizienz durch Vermeidung nichtdifferenzierender Entwicklung
- Fallbeispiele
Referent: OPITZ CONSULTING
12:00 Uhr Mittagspause
12:45 Uhr Spring kosteneffizient betreiben
- Monitoring und Administration
- tc Server, dm Server und Hyperic
- Praxisbeispiele
Referent: SpringSource
13:30 Uhr Get together
Labels: Opitz, Spring
EJB 3.1 Singletons considered harmful
Bevor wir zum Problem vorstoßen, zunächst einige Worte zu Singletons und Pooling. EJB hat vor 3.1 nur ein Modell mit Pooling von Bean angeboten. Der Grund für diese Entscheidung ist, dass man sich so nicht mit Multi-Threading in seiner Anwendung beschäftigen muss. Jeder Thread bekommt seine Instanz aus dem Pool, daher wird jede Instanz nur von einem Thread genutzt. Spring hingegen nutzt Singletons - von jeder Spring Bean gibt es typischerweise nur eine Instanz. Spring bietet auch die Option für Pooling - aber dieses Feature würde ich für den Preis des am wenigsten genutzten Features in Spring nominieren. Ich selber habe es bisher nur einmal produktiv verwendet - und nicht etwa, um Thread-Problemen zu entgehen, sondern um Ressourcen zu poolen. Die Nutzung von Singletons stellt bezüglich den Threads nämlich meistens kein Problem dar - weil die Beans fast immer Thread-Safe sind. Sie erhalten die Daten als Parameter, haben keinen eigenen Zustand und Ressourcen wie die Datenbankverbindung wird von Spring automatisch an den Thread gekoppelt. Dieses Modell wird in vielen Anwendungen genutzt und hat sich als sehr skalierbar erwiesen.
EJB 3.1 bietet nun als Neuerung auch ein Singelton-Modell an. Obwohl es aber mittlerweile unstrittig ist, dass Pooling praktisch nie wirklich benötigt wird, bleibt das Pooling der Default. Singletons sind vor allem dafür gedacht, um Datenstrukturen zu implementieren, die man nur einmal haben möchte. Dazu gehören zum Beispiel Caches. Es macht kaum Sinn, mehrere Instanzen eines Caches vorzuhalten. Man sollte lieber für alle Zugriffe dieselbe Instanz nutzen, weil man sonst mehrere Cache befüllen muss. Ein einfaches Singleton kann zum Beispiel folgendermaßen aussehen:
@Singleton
public class MyCache {
private Map cache = new ConcurrentHashMap();
public Object get(String key) {
return cache.get(key);
}
public void store(String key, Object value) {
cache.put(key, value);
}
}
Sieht jemand das Problem? Nun, wenn man diese Implementierung so nutzt, wird man ein erhebliches Skalierungsproblem haben. Überrascht? Lesen Sie weiter.
EJB 3.1 Singletons haben ein interessantes Feature. In der EJB-3.1-Spezifikation ist das Problem der Nebenläufigkeit gelöst worden. Dieses Thema dort anzusprechen ist gleich aus mehreren Gründen spannend:
- In Java gibt es mit synchronized und dem Package java.util.concurrent ausgesprochen gute Werkzeuge für Nebenläufigkeit. Es muss in diesem Bereich also keine Lücke gefüllt werden.
- Nehmen wir dennoch an, dass die Unterstützung für Nebenläufigkeit in EJB 3.1 eine sinnvolle Ergänzung ist. Warum ist sie dann auf EJB 3.1 beschränkt? Nebenläufigkeit ist ein fundamentales Problem und gehört nicht in eine spezialisierte API wie EJB.
- Außerdem ist Nebenläufigkeit bei den Singletons meist kein Problem, wenn man die Erfahrungen mit Spring zu Grunde legt. Zugegebenermaßen fokussiert EJB 3.1 aber auf Anwendungsfälle, bei denen man Datenstrukturen verwendet, die von mehreren Threads genutzt werden sollen, wie den Cache im Beispiel oben. Dort kann es dann sicher zu Nebenläufigkeitsproblemen kommen.
Das erinnert an eines der größten Probleme von EJB in Version 1.x und 2.x. Damals wurde mit Container Managed Persistence das Persistenz-Problem gelöst. Dabei wurden die bekannten Ansätze von O/R-Mappern ignoriert - so wie man jetzt die vorhandenen Nebenläufigkeits-APIs ignoriert. Und man hat eine Lösung in EJB implementiert, so dass man sie nur in einem Application Server nutzen kann - obwohl Persistenz genau wie heute Nebenläufigkeit ein viel allgemeineres Problem ist.
Wie funktioniert nun die Nebenläufigkeit bei EJB 3.1? Der Default ist Container Managed Concurrency. Alternativ kann man durch Bean Managed Concurrency die üblich Java-Bordmittel nutzen. Bei Container Managed Concurrency kann eine Methode mit
@Lock(READ) oder
@Lock(WRITE) markieren. Nur eine Methode mit einem WRITE-Lock kann zu einem Zeitpunkt aufgerufen werden. Keine andere Methode - weder mit READ- noch mit WRITE-Lock - darf dann in einem anderen Thread ausgeführt werden. Parallele Abarbeitung von Methoden mit READ-Locks ist hingegen erlaubt. Die Nebenläufigkeit an Methoden fest zu machen ist alleine schon Problem genug. Der Schlüssel zu einem skalierbaren System ist, dass man Locks so kurz wie möglich hält.
Ich hatte vor einiger Zeit einen Consulting-Einsatz wegen eines Skalierungsproblems. Das habe ich gelöst, indem ich diesen Code:
...
synchronized(cache) {
if (cache.get(key)==null) {
cache.put(aValue);
}
}
...
durch solchen Code ersetzt habe:
...
if (cache.get(key)==null) {
synchronized(cache) {
if (cache.get(key)==null) {
cache.put(aValue);
}
}
}
...
Dadurch wird der Cache nur noch gelockt, wenn er den Wert noch nicht enthält. Da der Cache irgendwann gefüllt ist, wird der Cache dann praktisch gar nicht mehr gelockt und man kann der Code dann mit wesentlich besserer Nebenläufigkeit betrieben werden. Wie man hier sieht, kann das Verschieben des Locking um eine Zeile schon einen erheblichen Unterschied machen. Wenn man solche Sachen mit den EJB-3.1-Annotationen machen will, wird man nicht weiterkommen, da sie nur auf Methoden wirken.
Schlimmer wird es nun dadurch, dass der Default ist, dass jede Methode ohne Annotationen so behandelt wird, als wäre sie mit
@Lock(WRITE) versehen. Das bedeutet, dass in dem
gesamten EJB-3.1-Singleton - wenn man nicht anderes definiert - nur ein Thread zur Zeit aktiv sein kann. Der oben mit EJB 3.1 implementierte Cache kann also nur von einem Thread parallel genutzt werden. Das wird in der Realität bei vielen parallelen Threads zu erheblichen Problemen führen. Da
@Lock(WRITE) der Default ist, sieht man gar nicht, was passiert, und muss man sehr genau verstehen, was hinter den Kulissen vor sich geht. Wer also einfach so mit EJB 3.1 los programmiert, wird in diese Falle tappen.
Besonders ironisch ist natürlich, dass der oben definierte Cache durch die
ConcurrentHashMap sowieso von mehreren Threads parallel genutzt werden kann. EJB 3.1 schüzt uns also ganz umsonst von der ach-so-komplizierten Welt der Nebenläufigkeit.
Labels: EJB 3.1, Pooling, Singletons
Event am 3.11. in Düsseldorf: Spring: Performance, Skalierbarkeit & Betrieb
Sie benutzen Spring zur Entwicklung Ihrer Anwendungen - aber was ist beim Betrieb und Performance-Tuning zu beachten? In diesem Seminar erhalten Sie Hinweise, wie man Anwendungen mit Spring effektiv betreiben kann und wie man typische Performance-Optimierungen vornehmen kann. Dabei stellen wir Ihnen Projekte wie die Hyperic HQ Open-Source-Monitoring-Lösung, Tomcat und dm Server vor.
Bitte registrieren Sie Sich unter
http://spring-performance.eventbrite.com/ - dort finden Sie auch den genauen Ablauf. Es wird ein Unkostenbeitrag von 99€ erhoben. Für das leibliche Wohl ist gesorgt.
Labels: Betrieb, dm Server, Hyperic, Performance, Skalierbarkeit, Spring, tc Server, Tomcat
