Spring Transacted JMS MDP over Glassfish V2 UR2

[aef]

Hi,

I am having a problem trying to migrate a Spring(2.5.6) based JMS MDP from weblogic to Glassfish (V2 UR2).

And im looking for some help, suggestions, or whatever information may help.

My MDP are all transactional, using XA transactions.

On weblogic im using the DefaultMessageListenerContainer with the WebLogicJtaTransactionManager and it works fine.

Now im porting it to Glassfish, so im still using a DefaultMessageListenerContainer and a JtaTransactionManager as a XA transaction manager. I am using Glassfish default transaction manager.

Both on Weblogic and Glassfish the connection factory are XA aware.

But sadly, under Glassfish the JMS Session Spring JMS listener uses is not transactional. And it should be transactional. Right?
I say the behaviour is not transactional, becouse the messages are not being consumed, becouse at commit time glassfish spits this error message:

[#|2008-11-19T17:09:38.697+0100|WARNING|sun-appserver9.1|javax.jms.Session.mqjmsra|_ThreadID=24;_ThreadName=listenerContainerConsultas-2;_RequestID=1f4c26cf-8ad5-466d-9449-3f1509987c6f;|MQJMSRA_DS4001: commit():Illegal for a non-transacted Session:sessionId=705408957070699778|#]

and the message is not removed.

I am doing something wrong in my applicationContext.xml?
Perphaps this scenario is not supported: by Spring?, by Glassfish?

Any sugestion?

Thanxs in advance.


This are the relevant part of applicationContext.xml (weblogic stuff commented)

    <!-- Beans listeners JMS -->
    <bean id="listenerContainerConsultas" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
        <property name="concurrentConsumers" value="5" />
     	<property name="maxConcurrentConsumers" value="5" />
     	<property name="idleTaskExecutionLimit" value="1" /> <!-- Time in minutes-->
     	<property name="connectionFactory" ref="connectionFactoryConsultasAdapter" />
     	<property name="destination" ref="queueConsultas" />
     	<property name="messageListener" ref="messageListenerConsultas" />
     	<!--<property name="transactionManager" ref="webLogicTransactionManager" />-->
        <property name="transactionManager" ref="springTransactionManager" />
     	<property name="sessionTransacted" value="true"/>
    </bean>
    
    <bean id="springTransactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
        <property name="transactionManagerName" value="java:appserver/TransactionManager"/>
    </bean>
    
    <!--<bean id="webLogicTransactionManager" class="org.springframework.transaction.jta.WebLogicJtaTransactionManager">
     	<property name="transactionManagerName" value="javax.transaction.TransactionManager"/>
    </bean>-->

[aef]

Ok i've being working is this thing and i made some progress :-)

The warning message i am getting at glassfish saying that the session is not transactional is caused by JmsResourceHolder.commitAll(), that invokes commit() over the JMS session.

That is being invoked whenever the messages are processed under a Local JMS transaction of a XA/JTA transaction.

Commiting a JMS session running under a JTA transaction is pointless? Anyway, apart from the warning message it seems harmless...


But... the main problem persists, the messages are still not processed in a transactional way.

For instance i send 100 messages to my input queue.. and they are being processed 300 times... instead of 100 times...
Several listeners are processing the same message at the same time¿?

Why is this happening?

Running under a XA/JTA transaction is enough to expect one time delivery?

I'm confussed...

This maybe related to a potential Glassfish bug, comments have been added to their bug report:

These are urls (remove whitespaces)
https ://glassfish.dev.java.net/issues/show_bug.cgi?id=5401
http ://forums.sun.com/thread.jspa?threadID=5313842

And this bug too:

https ://glassfish.dev.java.net/issues/show_bug.cgi?id=5316

That would explain why the transactional nature of the process is broken.

I hardy can believe such a basic feature is failing in Glassfish, if its really a bug, lets hope it gets fixed with max. priority.