Wenn man weiß, an welchen Stellen man schrauben muß, ist der Austausch der Hypersonic DB durch eine PostgreSQL DB als DefaultDS des JBoss gar nicht so kompliziert. Leider kann man aber aufgrund der teils doch recht unübersichtlichen Konfigurations-Dateien des JBoss dabei einiges übersehen. Darum habe ich die wichtigsten Schritte hier nochmal zusammengefaßt.
JBROOT und JBSERVER
Für die Lesbarkeit wurden die Bezeichnungen des JBoss Installationsverzeichnis durch $JBROOT und der verwendeten JBoss Konfiguration durch $JBSERVER ersetzt. Ausgehend von einer JBoss-Installation in /opt/jboss-5.1.0.ga und der Verwendung der default-Konfiguration gilt also:
export JBROOT="/opt/jboss-5.1.0.ga" export JBSERVER="$JBROOT/server/default"
Datasource anlegen
Natürlich muß die Datenbank erstmal angelegt werden. In der psql Shell ist das schnell getan:
CREATE DATABASE jboss WITH owner=jboss encoding='UTF-8' template=template0;
Hier ist jboss ein zuvor angelegter Datenbank User-Account für die Authentifizierung des JBoss Prozesses. Als nächstes sollte man diese Datenbank dem JBoss bekannt machen. Bisher residierte die HSQL Datasource Konfiguration in $JBSERVER/deploy/hsqldb-ds.xml. Diese Datei kann man ersetzen durch $JBSERVER/deploy/default-ds.xml:
<datasources> <local-tx-datasource> <!-- JNDI mapping name --> <jndi-name>DefaultDS</jndi-name> <!-- database connection info --> <connection-url>jdbc:postgresql://localhost:5432/jboss</connection-url> <driver-class>org.postgresql.ds.PGPoolingDataSource</driver-class> <user-name>jboss</user-name> <password>mypw</password> <!-- connection pool ranges --> <min-pool-size>20</min-pool-size> <max-pool-size>100</max-pool-size> <!-- time for a thread to wait for a requested DB-connection --> <blocking-timeout-millis>30000</blocking-timeout-millis> <!-- time to wait before freeing idle connections --> <idle-timeout-minutes>5</idle-timeout-minutes> <!-- prepared-statement cache config --> <prepared-statement-cache-size>20</prepared-statement-cache-size> <share-prepared-statements /> <!-- SQL dialect --> <metadata> <type-mapping>PostgreSQL</type-mapping> </metadata> </local-tx-datasource> </datasources>
Damit der JBoss mit dieser Datasource etwas anfangen kann, sollte man auch das Archiv mit dem passenden PostgreSQL JDBC Treiber nach $JBSERVER/lib kopieren.
JMS Persistence Provider einrichten
Nun ist es soweit, dem JBoss JMS Provider die neue Datasource etwas schmackhafter zu machen. Die bisherige, auf HSQL basierende, Konfiguration in $JBSERVER/deploy/messaging/hsqldb-persistence-service.xml kann durch eine Kopie des PostgreSQL Templates in $JBROOT/docs/examples/jms ersetzt werden:
cd $JBSERVER/deploy/messaging && \ rm hsqldb-persistence-service.xml cd $JBROOT/docs/examples/jms && \ cp postgresql-persistence-service.xml $JBSERVER/deploy/messaging
Das Template ist schon recht gut auf unsere Bedürfnisse zugeschnitten. Lediglich zwei Anpassungen sind ggf. noch nötig insofern man bei seiner JMS Lösung noch nicht auf Clustering angewiesen ist: Das Flag ”Clustered” sollte den Wert ”false” haben und die Dependency zur ”ChannelFactory” ist zu entfernen/auszukommentieren:
<attribute name="Clustered"> false </attribute> <!-- <depends optional-attribute-name="ChannelFactoryName"> jboss.jgroups:service=ChannelFactory </depends> -->
Hintergrund
HSQL ist für die Dauer der Entwicklung ein feines und unkompliziertes Werkzeug. Für den Live-Betrieb des JBoss – insbesondere wenn JMS im Spiel ist – kann es dann aber doch ganz schön auf die Bremse drücken. Aufgrund der “guaranteed delivery” Zusicherung des JMS Providers werden alle zu übertragenen JMS Nachrichten vor ihrem Versand – gewöhnlich in der Default Datasource – gespeichert (neudeutsch “persistiert“). Dieser Ansatz skaliert nicht besonders gut. Ein Austausch des RDBMS im Live-Betrieb wird schon in der JBoss Dokumentation dringend ans Herz gelegt.