EJB3, MDB, SonicMQ messages rolling back on undeploy it seem

[dbudworth]

Hi folks,

I have a simple EJB3 MDB deployed on my system, it comes up fine and processes all the messages in a queue (all it does it log the message id and return).

Problem is that when I shutdown jboss, the messages show up again in the message server.

I've tried specifically acknowledging the message in my onMessage handler, same issue.

I'm guessing that a TX gets started but never comitted (that's all I can imagine would be happening given that the message is semi-consumed).

My setup has the JBossMQ server removed (all config, removed deploy-hasingleton/jms). Added a custom service to bind sonic's XAConnectionFactory, XAQueueConnectionFactory, XATopicConnectionFactory. And modified the hajndi-jms service xml to point to each factory specifically rathen than all at the XACF. (sonic XACF doesn't implement XAQCF or XATCF).

Everything looks correct. It may be that I need to some how 'make transactions happen'... just not sure how.

I turned on debug logging for org.jboss.tm and org.jboss.ejb3 and see the deploy go fine, but i never see the TM log anything when the MDB deploys or when a message is received.

Is there some magic that must happen to turn on transactions wrapping around onMessage()? (I also tried setting @TransactionAttribute on onMessage, but that didn't make a difference).

[dbudworth]

After a bit more digging, it seems that the TM shows that the transactions were comitted.

Which leads me to believe that the connections returned from the sonic connection factories are not being enroled in the transaction.

Basically I only replaced the actual factories (and pointed JMSProviderLoader) to them.

Is there something special I must do to ensure that the connections get enrolled? Possibly proxy the connection factories and just forcibly enroll them if a tx is active? That won't help for the jta getResource() -> start tx -> enroll previous resource in tx type deal.

I'm thinking that maybe the ejb3 forum is the wrong place for this now? Looks like a generic problem rather than specific to ejb3/mdb