| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| WMB Transaction timeout value. |
« View previous topic :: View next topic » |
| Author |
Message
|
| tonyindl |
 Posted: Thu Sep 29, 2011 9:01 am Post subject: |
 |
|
Novice
Joined: 21 Dec 2010
Posts: 13
|
| paintpot wrote: |
So it is trying to be a batch program. What is the affinity between the messages (inside the original message)?
Often, the end useer is happiest if most of the data is processed and the odd one is dealt with my exception if it is an issue. Alternatively, maybe the messages below to different account numbers - you can batch (group) by the account number so that money is processed in order (and a whole group fails at once - which could be the right answer.
People don't normally do uber-transactions, because they will hit a limit at some point and then break ( and here we are! :D ). This can include databases getting locked etc.
Worst case, compensation may work for you (unwind the transactions of the 99.9% that worked when you hit an error).
look for the smallest grouping that has business meaning and send the messages based on that.
Your JCN code may be suspect if it takes a long time to split up one big message - I would look at the samples in the toolkit that use ESQL. The JCN code may have been written in an inefficient manner |
Actually , I don't know the relationships between the messages(inside the original message), but I am sure the end user can split this message into multiple pieces which may have 1000 messages each just as you mentioned,maybe based on business meaning.
So learn from mqjeff and your reply , it may be a good idea to process the smallest group of messages based on the business requirement if we have chance to refactor this flow and ESQL may be involved.
Thanks. |
|
| Back to top |
|
 |
| tonyindl |
| Posted: Thu Sep 29, 2011 9:18 am Post subject: |
|
|
Novice
Joined: 21 Dec 2010
Posts: 13
|
I got an immediate answer from a senior developer there is no such a configuration to set the transaction timeout value in broker.He guessed the message failed after ran for 80 mins due to the memory issue.
If no memory issue , the transaction may keep running till the process is done.
That sounds meaningful. |
|
| Back to top |
|
|
| paintpot |
| Posted: Thu Sep 29, 2011 11:50 pm Post subject: |
|
|
Centurion
Joined: 19 Sep 2005
Posts: 112
Location: UK
|
Yep - good ESQL will cure your memory issue - just follow the samples. Though sounds like you have the quick solution done for now (which sounds cheap?).  |
|
| Back to top |
|
|
| tonyindl |
| Posted: Mon Oct 03, 2011 11:27 am Post subject: |
|
|
Novice
Joined: 21 Dec 2010
Posts: 13
|
| paintpot wrote: |
| Yep - good ESQL will cure your memory issue - just follow the samples. Though sounds like you have the quick solution done for now (which sounds cheap?). :clap: |
Hi paintpot,
Thanks for your support , I have no idea how much our current solution would cost, but it should be cheaper than a change requirement. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
