Donnerstag, 21. Januar 2010

Datenbank-Ressource in Tomcat einbinden

Das das verwenden von Connection Poos eine tolle, Performance steigernde Sache ist hat sich sicher herumgesprochen. Nun gibt es verschiedene Möglichkeiten einen DB Connection Pool zu benutzen. Man kann natürlich auch selber entsprechende Logik in eine zentralen Datenbankklasse implementieren. Bei Serversoftware ist eher davon abzuraten, weil man dann das Connection Management komplexer wird. So schliesst die Datenbank von ihrer Seite aus eine Connection nach einer festgelegten Zeit der Inaktivität um Ressourcen zu sparen, bei MySQL sind dass 8 Stunden, d.h. wenn 8 Stunden lang keine Daten über die Datenbank Connection geflossen sind schliesst die Datenbank die Verbindung. Dies bemerkt man in der Regel erst am nächsten Tag oder am Montag, wenn man versucht Daten von Datenbank zu holen. Die Lösung lautet, man muss immer prüfen ob die Connection noch funktioniert, das macht man in dem man eine Datenbankabfrage macht, die immer ein definiertes Ergebnis liefert. Das prüfen der DB-Connection reicht nicht.
Zurück zum Pooling, Tomcat bietet ein eigenes Pooling mittel Tag resource. Das sieht in der Datei META-INF/context.xml der Webapp wie folgt aus:
<Resource
name="jdbc/MYSQLDB"
auth="Container"
type="javax.sql.DataSource"
username="smartblu"
password="xxx"
url="jdbc:mysql://localhost:3306/igd"
driverClassName="com.mysql.jdbc.Driver"
maxActive="500"
maxIdle="100"
maxWait="10000"
validationQuery="select count(*) from USER"
removeAbandoned="true"
logAbandoned="true"
/>

Mit validationQuery gibt man die oben erwähnte Wartungsabfrage an, mit der DB-Connection-Pool die Datenbankverbindung testen kann. Was jetzt noch fehlt, ist die Referenzierung der Datenbankressource in der Datei web.xml.

<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/MYSQLDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

Mittwoch, 20. Januar 2010

Dependency Management mit Ant

Genau. Einer der oft genannten Vorteile von Maven im Vergleich zu Ant ist das Dependency Management. D.h. in Maven muss man nur angeben welche Bibliotheken man für das Softwareprojekt braucht und Maven lädt die JARs dann automatisch aus dem Internet und legt sie im lokalen Repository ab. Bei Ant muss man die JARs selber laden und verwalten. Dies ist nicht notwendig wenn Apache Ivy eingesetzt wird. Ivy übernimmt das Dependency Management bei Ant-Projekten. Das schöne an Ivy ist die Kompatibilität zu Maven. Die Beschreibung der Bibliotheken erfolgt nach dem gleichen Prinzip und benutzt auch das zentrale Maven Repository. Aktuell gibt es bei IT Republik einen Artikel zu Ivy.

Mittwoch, 13. Januar 2010

Brownfield Projekte

Nicht alle Projekte starten auf einer grünen Wiese oft oder meistens beziehen sich Projekte auf vorhandene Software, den so genannten Brownfield Projekten. Wie kann man trotz dieser existierenden und oft laufenden Software die Grundsätze der CCD (Clean Code Developer). Mit diesem Thema beschäftigen sich zwei Artikel auf Heise Developer. Ich denke vielen Entwicklern werden einige Dinge bekannt vorkommen.

Dienstag, 5. Januar 2010

Maven vs. Ant

"Maven - eine Ausgeburt der Hölle", das ist ein toller Aufmacher von JAXenter. Das Zitat stammt von Kent Spillner, aus diesem Artikel. Interessant ist, dass Ant zumindest das zweit beste Build-Tool ist. Was sich dahinter versteckt, ist ein tiefer Frust über Maven. Maven sollte das Leben und den Build vereinfachen. Mein Urteil ist noch nicht gefällt. Auf jeden Fall sollt man diesen Blog-Eintrag lesen, oft habe ich mit dem Kopf genickt. Maven bringt aber noch andere Probleme mit sich, die zum Teil aus der Transparenz der Vorgänge in Maven herrühren. Das Dependency-Management ist einer der Argumente für Maven. Mein erstes Problem, wie heisst das Artefakt. Ausserdem lädt das Depency-Management alle möglichen Pakete, egal ob ich sie nötig sind oder nicht. Die Frage ist das ein Problem oder nicht, ich merke davon nichts und ich hab' keinen Einfluss drauf. Doch da fällt mir ein Nachteil ein, wenn ich Web-Applikationen entwickle und deploye muss ich ein grösseres WAR-transferieren, das kostet mehr Zeit und was das für bedeutet, kann man bei Joel Splonsky nachlesen.
Ein Kritikpunk von Kent Spiller, dass das Maven-Paradigma "Convention over Configuration" bei fast jeder Anforderung an den Build-Prozess nicht stimmt kann ich nachvollziehen, vor allem bei grösseren Projekten. Meine Idee ist es Projekte stärker zu modularisieren und jedes einzelne Projekt mit Maven zu realisieren. Vorteile sind überschaubare, wenig modifizierte (konfigurierte) POMs. Am besten man richtet dann auch gleich ein eigenes Remote-Repository ein, wie in diesem Blog beschrieben. D.h. benutze Maven bei grossen, modularen Projekten, sonst nehme lieber Ant.
Aber es ist schon ein Ärgernis, dass man bei Maven so viel konfigurieren muss und dass die Dokumentation spärlich ist. Ein andere Tipp ist, komplexere Anforderungen via Ant zu realisieren.