"weston.price(a)jboss.com" wrote : | The spec is merely saying that if the client is using a transacted session, then the ack mode is AUTO_ACKNOWLEDGE which is just simply a convention in this case as has no overall effect. I realise that if the session is transacted, then the ack mode is ignored, but that's not what the spec is saying. Here it is in full: EJB 2 spec 15.4.8: anonymous wrote : | If bean managed transaction demarcation is used, the message receipt cannot be | part of the bean-managed transaction, and, in this case, the receipt is acknowledged by the container. If | bean managed transaction demarcation is used, the Bean Provider can indicate in the | acknowedge-mode deployment descriptor element whether JMS AUTO_ACKNOWLEDGE semantics | or DUPS_OK_ACKNOWLEDGE semantics should apply. If the acknowledge-mode deployment | descriptor element is not specified, JMS AUTO_ACKNOWLEDGE semantics are assumed. | What the spec is saying, is that if you are using BMT then the message receipt will be acked using a local non transacted session, that is either AUTO_ACK or DUPS_OK, AND if the user omits to specify which ack mode in the deployment descriptor then it will use AUTO_ACK. This ack mode is *not* ignored, it used for the message receipt. What I observe in practice, using JBM and the 4.0.5.GA JCA, is that if I specify the ackmode, then it all works fine (my trivial example), the message is received and acknowledged. If I fail to specify the ack mode, I can see the JCA layer creating a *transacted* XA session, and trying to call commit on it. Bottom line is JBM works with the JMSContainerInvoker but not with JCA inflow in 4.0.5, even for this most trivial example. I'm not trying to attribute blame, just trying to work out what is going on, and find a solution. :) This is either a problem in JBM or a problem with JCA. Right now I believe it is a bug in JCA because the JCA layer is trying to call commit on an XASession which seems clearly wrong to me. Although I am willing to accept there is a bug in JBM if you can come up with another explanation. If you are saying that the 4.0.5.GA code is a bodged backport and basically doesn't work, and there's no chance of getting it fixed, then we can tell our customers not to use that and stick with the JMSContainerInvoker until JB5. (What about AS4.2 - I would have thought we would want the good HEAD version in that?) This isn't ideal but if that's the situation, then we have to live with that. For JBM1.2, we need to make sure that all these cases work, so I am going to improve the MDB integration tests and make sure they run with both the JMSContainerInvoker and JCA1.5 inflow. Right now the MDB test coverage is scrappy (no blame) to say the least which is why issues like this and others are slipping through the net. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001488#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...