From the EJB 3.1 Spec:
8.3.5 Use of JMS APIs in Transactions
The Bean Provider should not make use of the JMS request/reply paradigm (sending of a JMS message, followed by the synchronous receipt of a reply to that message) within a single transaction. Because a JMS message is typically not delivered to its final destination until the transaction commits, the receipt of the reply within the same transaction will not take place.
Because the container manages the transactional enlistment of JMS sessions on behalf of a bean, the parameters of the createSession(boolean transacted, int acknowledgeMode), createQueueSession(boolean transacted, int acknowledgeMode) and createTopicSession(boolean transacted, int acknowledgeMode) methods are ignored. It is recommended that the Bean Provider specify that a session is transacted, but provide 0 for the value of the acknowledgment mode.
The Bean Provider should not use the JMS acknowledge method either within a transaction or within an unspecified transaction context. Message acknowledgment in an unspecified transaction context is handled by the container. Section 8.6.5 describes some of the techniques that the container can use for the implementation of a method invocation with an unspecified transaction context.
Thanks for your reply,
so the answer to question 1 is yes. What about q 2 and 3?
1 of 1 people found this helpful
by default in managed environment a session object is created from connection that is enlisted in a transaction
so that all producers and consumers created from session send and receive messages as an atomic unit of work
ad 1) session is always transacted regardless of supplied parameters of createXXXSession()
ad 2) simply this call is only relevant in unmanaged environment
ad 3) you should call Session.commit() in unmanaged environment if the session has been created as transacted
It's worth noting that everything said in reply to your question really depends on the connection you are using.
Stephen and Radim's comments are accurate if you are using a JCA based JMS connection factory (e.g. "java:/JmsXA"), since the connections are "managed." Using a JCA based JMS connection factory is generally recommended because it has numerous benefits.
However, if you are using a non-JCA based JMS connection factory (e.g. "java:/ConnectionFactory") then you can do all those things which the Java EE says you shouldn't do because you'll be using a un-managed connection.
See this documentation for more info on the different kinds of connection factories.
Thanks for clearing that Justin. I tried them both and I saw different results, that's why I opened this thread.