| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JMS Sessions Synchronised in a Connection? |
« View previous topic :: View next topic » |
| Author |
Message
|
| pauillac |
 Posted: Wed Sep 26, 2001 11:25 pm Post subject: |
 |
|
Novice
Joined: 13 Jul 2001
Posts: 21
|
Hi,
According to "MQSeries Using Java" Multithreaded Programs Section on p.62,
"The implementation of MQSeries classes for java ensures that for a given connection (MQQueueManager object instance), all access to the target MQSeries queue manager is synchronized. Therefroe, a thread wishing to issue a call to queue manager is blocked until all other calls in progress for that connectioin are compelete."
This is a problem if I do request/reply messaging. The thread waiting for the reply message will occupy the connection. If my client application wants to concurrently issue 1000 requests for workload simulation, then it will have to open 1000 connections for concurrency. This would not be acceptable.
I would like to know whether the same restriction is imposed on JMS Sesssions in a Connection. In other words, can I open multiple JMS sessions in a JMS connection to achieve concurrency that MQSeries classes for Java fail to do?
Thanks
|
|
| Back to top |
|
 |
| kolban |
| Posted: Thu Sep 27, 2001 5:55 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Some clarity first ... MQSeries provides two seperate and distinct class libraries for working with Java. One is a proprietary API designed for accessing all the functions of MQSeries from Java. This class library is termed "MQ base java". This set of classes give access to all the low level functions of MQSeries and pre-dates JMS by a long time.
The other class library is IBM's implementation of the JMS specification. This allows a Java application to be written which conforms to the JMS spec and, at run time, utilizes MQSeries as the underlying messaging and queuing transport.
The section you reference in the manual corresponds to MQ base Java and not JMS ...
.... But even so, in the JMS specification, it clearly states that the thread that creates the JMS Session is the ONLY thread that can access the session.
So ... how can we acheive what you want? The answer is to design your application with one request sender thread and one request responder thread. When your application sends a request on one thread it is then able to process the next request immediately after sending the request.
The responder thread is waiting for responses to arrive. When a response arrives, it is processed. Although you didn't state it as a problem in your posting, I suspect your concern is that you need to correlate responses back to the original requests. Perhaps your program is receiving requests itself and acts as a gateway or proxy into MQSeries?
If this is the case, you are still ok since MQSeries has designed into it the concept of a "Correlation ID". This is a piece of information in a response message which allows it to be uniquely associated with an initial request. It would then be up to your application to map the items together, perhaps using a Java collection object like a hash-table. |
|
| Back to top |
|
|
| pauillac |
| Posted: Thu Sep 27, 2001 6:49 pm Post subject: |
|
|
Novice
Joined: 13 Jul 2001
Posts: 21
|
Hi,
Thanks for your reply. Actually, I am using correlation ID for matching request and reply messages. However, the main problem I encounter is I want to do real synchronous processing. The thread initiates the request message must wait for the reply message. It is because the request initiator is an on-line application. Say, if the user makes an account enquiry txn using the client application. The client application then sends a message to the host through MQSeries. The client application should not return before it receives the reply message containing account enquiry details. (using correlation Id for matching) So using a request thread for sending messages and a response thread for receiving messages is a good design but it is not what I want to do because I want to suspend the response to the client to simulate RPC call.
The limitation imposed on MQ base Java classes is that all request messages sent thru the same connection is serialized, i.e. a thread having sent a request message must wait for the reply message before another request can be sent to the QM. If I want to send multiple requests at the same time, it means I have to open as many QM connections as the number of requests I want to send at the same time. This would be too resource intensive, especially I uses a single NT machine to run a client application simulator to issue 1000 or more concurrent access to a QM on an AIX machine.
In JMS every Session can only be accessed by a single thread but I don't know if I open multiple JMS sessions (threads) in a single JMS connection, the serialization limitation is still valid for those JMS sessions because JMS is implemented on top of MQ base Java Classes. Any idea?
Thanks a lot. |
|
| Back to top |
|
|
| kolban |
| Posted: Thu Sep 27, 2001 7:39 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
With MA88, there is the concept of connection pooling. This means that previous queue manager connections can be reused without incurring the expense of a new connection.
You can still achieve the "apparent" synchronization without resorting to multiple threads. How is your "client" communicating with the MQ program? What causes the return? Although threads may seem an obvious choice, I still believe that a non-threaded (or few threaded or "not a thread per client") solution is still workable. |
|
| Back to top |
|
|
| middlewareonline |
| Posted: Mon Oct 15, 2001 12:10 pm Post subject: |
|
|
Acolyte
Joined: 09 Jul 2001
Posts: 73
|
| Quote: |
On 2001-09-27 20:39, kolban wrote:
With MA88, there is the concept of connection pooling. This means that previous queue manager connections can be reused without incurring the expense of a new connection.
You can still achieve the "apparent" synchronization without resorting to multiple threads. How is your "client" communicating with the MQ program? What causes the return? Although threads may seem an obvious choice, I still believe that a non-threaded (or few threaded or "not a thread per client") solution is still workable.
|
How do we use connection-pooling provided by MA88 ? Are you referring to pool classes (MA Series classes for Java) or JMS implementation ? I would like to know, if anyone has tried JMS connection-pooling (if one even exist).
Chris
_________________
---------------------------------------------
IBM & SUN (J2EE) Certified Consultants,
http://www.MiddlewareOnline.com
A "SARVAM" Online Portal
http://www.SARVAM.com
--------------------------------------------- |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
