Transaction propagation and MDB

[qtm]

Hi,

Given a situation like:

@MessageDriven(name="testMDB", activationConfig =

{

    @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "AUTO_ACKNOWLEDGE"),

    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),

    @ActivationConfigProperty(propertyName = "destination", propertyValue="queue/test")

})

public class TestMDB implements MessageListener{

     @Resource(..)

     private Queue queue;

     @Resource(...)

     private ConnectionFactory connectionFactory;

     public void onMessage(Message message){

           Connection con = null;

           try{

               con = connectionFactory.createConnection();

               con.start();

               Session session = con.createSession(false, Session.AUTO_ACKNOWLEDGE);

               System.out.println(session.getTransacted());

              // some operations

              //session.commit();

               session.close();

           } finally{

               if (con != null){

                        con.close();

                }

           }

     }

}

So my MDB has container managed transactions and the transaction attribute REQUIRED.

1. Will the container always create a transactioned session ignoring what I've given as parameters (false, Session.AUTO_ACKNOWLEDGE) ?

2. If so, why does session.getTransacted() return false if I create it like above?

3. If so, is it necessary to call session.commit()? Since I'm closing the session at some point how does the container commit the session? It intercepts send/receive method calls?

Thanks

[sfcoy]

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.

[qtm]

Thanks for your reply,

so the answer to question 1 is yes. What about q 2 and 3?

[sfcoy]

http://jcp.org/aboutJava/communityprocess/final/jsr318/index.html

[rhanus]

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

[jbertram]

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.

[qtm]

Thanks for clearing that Justin. I tried them both and I saw different results, that's why I opened this thread.