Probleme, Probleme, Probleme…
Beim Versuch den Enterprise Service Bus (ESB) von JBoss in den Griff zu bekommen stieß ich heute auf folgende Hürde: Beim Hochfahren meckert der JBoss-Server (JBoss AS 4.0.5, also topaktuell):

10:32:40,531 WARN [ServiceController] Problem starting service
jboss.mq:service=PersistenceManager
org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions.
Message recovery may not be accurate; - nested throwable:
(com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Every derived table
must have its own alias)
at org.jboss.mq.pm.jdbc2....resolveAllUncommitedTXs(PersistenceManager.java:492)
...
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
... at blablabla ...
at org.jboss.Main$1.run(Main.java:490)
at java.lang.Thread.run(Thread.java:595)
Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException:
Every derived table must have its own alias
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
... at blubber, sülz ...
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.
executeQuery(WrappedPreparedStatement.java:236)
at org.jboss.mq.pm.jdbc2.PersistenceManager.
resolveAllUncommitedTXs(PersistenceManager.java:424)
... 111 more

Nach einigen Nachforschungen hat sich herausgestellt, dass das folgende SQL-Statement von der MySQL-Datenbank hochnäsig zurückgewiesen wurde:

SELECT_MAX_TX = SELECT MAX(TXID) TXID FROM
(SELECT MAX(TXID) AS TXID FROM JMS_TRANSACTIONS
UNION SELECT MAX(TXID) AS TXID FROM JMS_MESSAGES)

Warum? Weil das Subselect offensichtlich auch einen Alias benötigt. Na von mir aus. Ein Schmökern in den JBoss-Foren und im JIRA hat mir auch nicht wirklich weitergeholfen. Beim Vergleich diverser User-Erfahrungen stellte sich herau, dass das Problem nicht auftritt, wenn man MySQL in einer Version größer als 4.0.13 und kleiner als 4.0.20 verwendet. Naja. Mit meiner brandheißen 5.0.27 bin ich da ja weit von entfernt. Im Bugtracker diskutieren die Entwickler lediglich die Frage, ob der Bug gefixt wird, dass er ja eigentlich schon gefixt ist, warum er dann nicht im Release ist, das das wohl vergessen wurde, ob er denn überhaupt gefixt werden muss, usw. usw…

Nun, die Lösung ist einfach:

Man schnappe sich die die Datei
[jboss.root]/server/default/deploy/jms/hsqldb-jdbc2-service.xml

und ändere diese Zeile:
SELECT_MAX_TX = SELECT MAX(TXID) TXID FROM
(SELECT MAX(TXID) AS TXID FROM JMS_TRANSACTIONS
UNION SELECT MAX(TXID) AS TXID FROM JMS_MESSAGES)
wie folgt ab:
SELECT_MAX_TX = SELECT MAX(TXID) TXID FROM
(SELECT MAX(TXID) AS TXID FROM JMS_TRANSACTIONS UNION
SELECT MAX(TXID) AS TXID FROM JMS_MESSAGES) AS ichbindergottverdammtealias

Nun erzählt mir mein lieber JBoss Server noch dass die Tabelle JMS_TRANSACTIONS nicht existiert. Also in der selben Datei nochmal kurz gepatcht. Folgende Zeilen:

CREATE_MESSAGE_TABLE =
CREATE CACHED TABLE JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL,
DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1),
MESSAGEBLOB OBJECT, PRIMARY KEY (MESSAGEID, DESTINATION) )
CREATE_TX_TABLE = CREATE CACHED
TABLE JMS_TRANSACTIONS ( TXID INTEGER, PRIMARY KEY (TXID) )

ändern zu:
CREATE_MESSAGE_TABLE =
CREATE TABLE JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL,
DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1),
MESSAGEBLOB BLOB, PRIMARY KEY (MESSAGEID, DESTINATION) )
CREATE_TX_TABLE = CREATE TABLE JMS_TRANSACTIONS ( TXID INTEGER, PRIMARY KEY (TXID) )


Nun ist Ruhe.