jms-source cannot be configured with a jms-template

hey Mark..Sorry for my ignorance about the transacted session there..I understand now that it will commit only after a send..
The use case that I have though doesnt expects me to send a response immediately..this is sort of asynchronous receive and an asynchronous send that I will be doing later <triggered seperately> .
Is there a way that I can commit this transaction w/o sending something back on the channel ?

Sorry, I'm not talking about replying to a JMS queue - rather I was referring to the sending of a Spring Integration Message object to a Spring Integration MessageChannel. As soon as a JMS Message is received by the JmsMessageDrivenSourceAdapter it does automatically convert and send to a Spring Integration MessageChannel. Based on the configuration that you posted earlier, it would be "MyRequestChannel" in your case. The JMS Session should be committed as soon as the message is sent to that channel. Does that make sense?

-Mark

If that is the case then its flowing to my channel quite alrite ..why is it not being removed from the queue then..

I have an endpoint registered on that channel and the handler does receives the message alrite ..

Code:

---

<endpoint input-channel="RequestChannel"
                          handler-ref="messageListener"
                  handler-method="onMessage"/>

---

I've just run through some local tests with a debugger, and I see the JMS Message being removed from the queue as soon as session.commit() is invoked after the sending method returns. Can you provide some information about your environment and/or how you are determining that the JMS Messages are not being removed from the queue? Also do you know which release of Spring Integration you are using (either the Milestone-1 release or else a SVN r#) ?

Thanks,
-Mark

Im listening on a regular MQ queue using <jms-source> . The channel and adjoining handler recieves the message correctly. The MQ Browser still shows me the message on the queue and I receive it again on the next run..

Instead if I use jms-listener , I see that the queue is being drained..

I find this very strange too, wondering what might be causing this..

Im using the SVN release 1.0.0.m2.20080218 at the moment, but was facing the same issue with 1.0.0.m1 too.
Which is the class that actually does session.commit() ?
Maybe I can debug this thing to better understand the flow..

Appreciate your help and patience with this issue !

Try adding a breakpoint in: AbstractMessageListenerContainer.commitIfNecessary (..)

That is in the spring-jms.jar.

-Mark

I ran debug test and see that the commit is not actually being done , its being skipped at

Code:

---

// Commit necessary - but avoid commit call within a JTA transaction.
if (isSessionLocallyTransacted(session)) { skips }
returns back..

---

within

Code:

---

protected void commitIfNecessary(Session session, Message message) throws JMSException {
        // Commit session or acknowledge message.
        if (session.getTransacted()) {
          // Commit necessary - but avoid commit call within a JTA transaction.
          if (isSessionLocallyTransacted(session)) {
                        // Transacted session created by this container -> commit.
                        JmsUtils.commitIfNecessary(session);
          }
        }
        else if (isClientAcknowledge(session)) {
                message.acknowledge();
        }
}

---

The actual code that denies commit seems to be

Code:

---

protected boolean isSessionLocallyTransacted(Session session) {
                return super.isSessionLocallyTransacted(session) &&
                                !ConnectionFactoryUtils.isSessionTransactional(session, getConnectionFactory());
        }

---

How is my jms transaction part of JTA <as the commit didnt happen because of that > and what can be done to change that ?

Any updates on this ? How do I make sure the session is commited ?

Since your listener is receiving within a JTA transaction, the commit is not going to happen within the local scope of the JMS Session at all. Are you intentionally using a JTA-managed transaction here?

-Mark