| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JMS cannot acknowledge from a different thread but can mqlib |
« View previous topic :: View next topic » |
| Author |
Message
|
| steffi2 |
 Posted: Fri Aug 27, 2010 11:05 am Post subject: JMS cannot acknowledge from a different thread but can mqlib |
 |
|
Apprentice
Joined: 04 Sep 2009
Posts: 31
|
So, in JMS if I have an Message listener I cannot receive a message via onMessage and then acknowledge this message via the session in a different thread. That is forbidden by the JMS spec.
I'm asking if this possible using native mqlib with Java.
Can I commit a transaction in a separate thread if I received the message in a different thread?
so I'd want to set up a listener via callback in one thread to receive all my messages distribute the work to worker threadpool and only when the job is complete do I want to commit the transaction. Is that possible using mqlib since it's not possible with JMS. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Aug 27, 2010 2:14 pm Post subject: Re: JMS cannot acknowledge from a different thread but can m |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| steffi2 wrote: |
So, in JMS if I have an Message listener I cannot receive a message via onMessage and then acknowledge this message via the session in a different thread. That is forbidden by the JMS spec.
I'm asking if this possible using native mqlib with Java.
Can I commit a transaction in a separate thread if I received the message in a different thread?
so I'd want to set up a listener via callback in one thread to receive all my messages distribute the work to worker threadpool and only when the job is complete do I want to commit the transaction. Is that possible using mqlib since it's not possible with JMS. |
I see trouble there. Remember that the acknowledgement or transactionality is not done at the message level. This is done at the session level (JMS). Or at MQCOMMIT time (java base).
Thus all messages since last commit or start of session , or all messages in syncpoint are subject to the transaction commit.
If you want to use some kind of parallelism on message processing from within the session, you can potentially pass the message to a processing thread that uses it as synchronization object. When all the messages are done all the synchronization objects are accessible to the current session's main thread and you can commit.
I know it gets quite complex, but you have to conserve the session's integrity for the transactional boundary...
It would be way easier to use an MDB design and implement multiple instances of the MDB.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Aug 28, 2010 6:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The real question here is How Many is " all my messages"?
You need to establish a transaction boundary of some kind. You need to say "I am going to read 1 message in a single transaction" "I am going to read 10 messages" or "I am going to read 100 messages".
You DO NOT want to say "I am going to create a transaction with all of the messages that are in the queue at this time". You *twice* as much DO NOT want to say "I'm going to create one transaction for the lifetime of the MDB listener". Even if everything works, your MQ admin will still show up at your desk with 
If nothing else, ask yourself how many instances of your worker thread do you want running at a single time?
Also ask yourself what you are doing with EACH message. Are you merely consuming it? Or are you doing some processing on it that requires an additional resource - a database insert, a reply message, etc. If so, you then have an additional transaction to consider. |
|
| 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
|
|
|
|
