| Author |
Message
|
| zpat |
 Posted: Fri Sep 26, 2008 4:34 am Post subject: JMS with client connection and syncpoint |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I am not a Java or JMS programmer, but understand the MQI pretty well.
This question is about a single phase message commit (and not about XA) with a MQ client connection to a non-mainframe QM. All this is simple enough in MQI.
But how does a JMS programmer specify MQGMO_SYNCPOINT or MQPMO_SYNCPOINT?
If it's on the session level - how does one change this per message get or put?
Can someone refer me to a JMS to MQI comparison table (and I don't mean the IBM MQ Using Java manual)? |
|
| Back to top |
|
 |
| atheek |
| Posted: Fri Sep 26, 2008 11:31 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
In JMS you can operate the sessions in 2 modes:
1. Transacted Mode
2. Acknowledgment Mode ( Client Acknowledgement or Auto Acknowledgement)
Which mode you are using is determined from the createSession call which takes the syntax
connection.CreateSession( transacted, ack mode),
where transacted is a boolean value indicating whether session is transacted or not. If this is set to true, then the 2nd parameter becomes insignificant. If transacted is false, then the session is non transacted and uses the acknowledgement mode and what ack mode is determined by the 2nd parameter.
Now to understand how these 2 modes relate to Syncpoints, lets discuss the different scenarios:
Scenario 1
==========
Session : Transacted
Ack Mode: Irrelevant
All Send's and receive's within this session are implicitly in SYNCPOINT and the UOW commits/rollbacks when session.commit() or session.rollback is called respectively.
Scenario 2
==========
Session : Non Transacted
Ack Mode: AUTO ACK
All send's and receives are implicitly outside the SYNCPOINT and all puts/gets are committed immediately when producer.send() or consumer.receive() calls get completed succesfully.
Removed as corrected by FJB_SAPER in the below post
Scenario 3
==========
Session : Non Transacted
Ack Mode: CLIENT ACK
All Send's and receive's within this session are implicitly in SYNCPOINT and the UOW commits/rollbacks when message.acknowledge() or session.recover is called respectively.
The commit syntax is bit strange as a method on message is called for this purpose. When message.ack(() is called all messages which were processed before this message and yet to be committed gets committed.
Last edited by atheek on Sun Sep 28, 2008 3:15 am; edited 3 times in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 26, 2008 8:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| atheek wrote: |
The only exception is if you are getting the message asynchronously, using a message listener. In this case the get is committed only when onMessage() method is completed succesfully.
|
I beg to differ here. The onMessage() method is still governed by the transactionality of the session or the container as the case may be.
In J2EE the transaction attribute is set on the method and thus governed by it. (It may determine the session used behind the scenes...)
In a stand alone I would expect the transaction attribute from the session in which the receiver was created (i.e. the active session) to carry over to the onMessage method.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Sep 26, 2008 10:51 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Thanks, it's fairly confusing but slightly important when dealing with high value messages! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 27, 2008 2:25 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
| Thanks, it's fairly confusing but slightly important when dealing with high value messages! |
WAS is a little bit particular as it specifically states that it overrides any of the transactional session attributes set in the code with the transactional attribute of the 'global transaction' .i.e. the J2EE setting will override whatever you coded and you might participate in a global transaction without having ever coded for it.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| atheek |
| Posted: Sat Sep 27, 2008 6:40 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
| fjb_saper wrote: |
| In a stand alone I would expect the transaction attribute from the session in which the receiver was created (i.e. the active session) to carry over to the onMessage method. |
| atheek wrote: |
Scenario 2
==========
Session : Non Transacted
Ack Mode: AUTO ACK
All send's and receives are implicitly outside the SYNCPOINT and all puts/gets are committed immediately when producer.send() or consumer.receive() calls get completed succesfully.
The only exception is if you are getting the message asynchronously, using a message listener. In this case the get is committed only when onMessage() method is completed succesfully. |
Hi FJ, I didn't understand your point...The scenario I mentioned was for non transacted auto acknowledge mode.. Could you explain what you mean by the transaction attribute from the session in which the receiver was created in your reply?
As per my understanding whatever I specified for scenario 2 is valid.. Please explain me why you differ with me for this particular scenario? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 27, 2008 8:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| atheek wrote: |
| fjb_saper wrote: |
| In a stand alone I would expect the transaction attribute from the session in which the receiver was created (i.e. the active session) to carry over to the onMessage method. |
| atheek wrote: |
Scenario 2
==========
Session : Non Transacted
Ack Mode: AUTO ACK
All send's and receives are implicitly outside the SYNCPOINT and all puts/gets are committed immediately when producer.send() or consumer.receive() calls get completed succesfully.
The only exception is if you are getting the message asynchronously, using a message listener. In this case the get is committed only when onMessage() method is completed succesfully. |
Hi FJ, I didn't understand your point...The scenario I mentioned was for non transacted auto acknowledge mode.. Could you explain what you mean by the transaction attribute from the session in which the receiver was created in your reply?
As per my understanding whatever I specified for scenario 2 is valid.. Please explain me why you differ with me for this particular scenario? |
You are specifying an exception here for the message listener. I don't think there is an exception. The message listener gets attached to a specified receiver. This receiver is created from a session. In a standalone environment I expect that session to govern transactionality.
In a J2EE environment the container transaction attribute for the method would take precedence and possibly get passed on to the session being used behind the scenes.
In other words, for the case you alluded to, as soon as the message is available to the onMessage method the receive is finished successfully and the get is committed.
The only way to avoid this and only commit on exit of the onMessage method is to have the session transacted. This I believe is the default for MDB's which is why you might have had that impression.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Sep 28, 2008 12:45 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Yes, I should have added, this will be in a WAS environment. |
|
| Back to top |
|
|
| atheek |
| Posted: Sun Sep 28, 2008 3:11 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
Thanks FJ for the clarification. I was bit misguided by the documentation in sun site..
| Quote: |
AUTO_ACKNOWLEDGE
public static final int AUTO_ACKNOWLEDGE
With this acknowledgment mode, the session automatically acknowledges a client's receipt of a message either when the session has successfully returned from a call to receive or when the message listener the session has called to process the message successfully returns.
|
I thought that ( in bold) indicated that acknowledgement is send when onMethod returns successfully.. I could see many documentation in the net which indicated this..
From http://www.javaworld.com/javaworld/jw-02-2002/jw-0315-jms.html
| Quote: |
| To implement the auto acknowledgement mode, when you create the receiver's session, specify false as the first argument and Session.AUTO_ACKNOWLEDGE as the second argument of the createSession() factory method. Specifying false creates a nontransacted session. The second parameter creates a session that automatically acknowledges messages. A message is automatically acknowledged when it successfully returns from the receive() method. If the receiver uses the MessageListener interface, the message is automatically acknowledged when it successfully returns from the onMessage() method. If a failure occurs while executing the receive() method or the onMessage() method, the message is automatically redelivered. |
But as you pointed out, I think this is incorrect..With asynchronous delivery and auto acknowledgment , the ack is send as soon as onMessage is invoked and doesn't wait for its completion. This makes sense why its not easy to have the receive and onMessage on the same transaction when using BMT. If above was true I could have specified AUTO_ACKNOWLEDGE as the ack mode and use BMT and still have both under the same transaction..There shouldn't be any need to use CMT for this purpose. But its not...' ' |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Sep 28, 2008 7:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Remember as well that different providers have different behavior. What is true for Sun is not necessarily true for IBM (unless that behavior is part of the JMS specification that IBM supports)
In any case to make sure you get the behavior you want I would have gone with CLIENT_ACKNOWLEDGE. This will hold the message until you have acknowledged a message.
Tell you the truth in JMS I nearly always use a transacted mode. It is so much easier when you know how you control the transaction (no surprises from a global transaction) and gives for better speed when retrieving messages from multiple connections / multiple threads
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Sep 28, 2008 11:43 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Can a single JMS thread open two sessions at the same time, one transacted and one not?
Is the session the equivalent of MQOPEN or MQCONN? |
|
| Back to top |
|
|
| atheek |
| Posted: Mon Sep 29, 2008 5:05 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
| zpat wrote: |
| Can a single JMS thread open two sessions at the same time, one transacted and one not? |
Yes. However no two threads can concurrently access the same session object
| zpat wrote: |
| Is the session the equivalent of MQOPEN or MQCONN? |
Well, session is equivalent of the neither. Sessions are created from Connections. Connections are associated with a particular queue manager.
Using sessions you can create multiple message producers ( equivalent of opening the queue for output) and multiple message receivers (equivalent of opening the queue for input).
Sessions define a transactional context involving one or more queues of a queue manager. How ever note that you can't use the same session to connect to 2 queues belonging to 2 different queue managers. This is because sessions are created from a connection and a connection is always associated with a particular queue manager |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 29, 2008 11:34 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Also there is a fundamental difference in resources for a connection and for a session:
A connection takes time to establish. This is why the J2EE model pools the connections. A session can be build at nearly no cost from the connection.
The problem is when you try to retrieve messages: You are using a single connection with multiple sessions: you can only retrieve as big as your connection pipe is and the connection will enforce the synchronize on your API calls.
You are using multiple connections each with a singe session. The bandwidth is not the connection bandwith but your tcp/ip bandwidth. Each connection will work in parallel with each other. For better performance it is recommended to have the sessions transacted.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
