| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Query on Commit Count setting on the BAR file |
« View previous topic :: View next topic » |
| Author |
Message
|
| McueMart |
 Posted: Wed Apr 16, 2014 6:24 am Post subject: Query on Commit Count setting on the BAR file |
 |
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
In the past I have never touched 'Commit Count' or 'Commit Interval' on my bar file, I have always just left it to the default of '1' and '0' respectively.
(Quick link for those who want to read about the properties:
http://pic.dhe.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fac09055_.htm&resultof%3D%2522%2563%256f%256d%256d%2569%2574%2522%2520%2522%2563%256f%2575%256e%2574%2522%2520
)
After doing my best to read about them, I'm still struggling to fully understand them and would appreciate if someone could verify if my understanding is correct.
The infocenter says in regards to Commit Count:
"For WebSphere MQ messages, this property specifies how many input messages are processed by a message flow before a sync point is taken (by issuing an MQCMIT command)."
Does this mean that the complete broker transaction isn't commited until Commit Count is reached? e.g. If I have:
Commit Count=50
MQInput => Compute (INSERT INTO DATABASE)
Does this mean that my flow will have to read 50 MQ messages and do 50 of the INSERTS before the transaction is committed? Or does Commit Count relate ONLY to the MQ aspect? If so how does that work??
Many thanks for any help! |
|
| Back to top |
|
 |
| Esa |
| Posted: Thu Apr 17, 2014 12:23 am Post subject: Re: Query on Commit Count setting on the BAR file |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| McueMart wrote: |
Does this mean that the complete broker transaction isn't commited until Commit Count is reached? |
No. The MQ transaction is committed when commit count is reached or commit interval has elapsed. The default value of commit interval is 0 which means that commit count is turned off. The max value is 60 seconds.
| McueMart wrote: |
e.g. If I have:
Commit Count=50
MQInput => Compute (INSERT INTO DATABASE)
Does this mean that my flow will have to read 50 MQ messages and do 50 of the INSERTS before the transaction is committed? Or does Commit Count relate ONLY to the MQ aspect? If so how does that work??
|
It works so that all MQ operations are included in one single MQ transaction. But it very likely doesn't work that way for DB transactions. For 50 messages you would get 50 separate DB transactions. Each of these transactions may be committed when the corresponding flow instance terminates or they could be left pending and committed just before MQ the MQ operation is committed after commit count or commit interval rule has fired.
My guess is that DB transactions are committed when the flow instance terminates. This should be quite easy to test: set commit interval to 60 seconds, send one message and you have almost one minute time to check if the DB operation was committed or not.
Please share the results with us, if you test it.
But: if your flow does database operations, the net effect on message rate that you get from adjusting commit count is neglible. IMHO.
By the way, I recall that commit count should only have effect on message flows that run with no additional instances. The InfoCenter doesn't mention that. Maybe this limitation has been removed? If it ever existed. Adjusting commit count is the only way to speed up flows that run on one instance only, maybe I have just misunderstood that it doesn't apply to flows with additional instances. |
|
| Back to top |
|
|
| McueMart |
| Posted: Thu Apr 17, 2014 2:11 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| But: if your flow does database operations, the net effect on message rate that you get from adjusting commit count is neglible. IMHO. |
Now you get to the real reason im asking this question  . We are doing synchronous database replication between DCs, so the number of database operations which can take place with a transaction is quite vital to us (As we incur a latency hit each time a DB transaction commits)
If the Broker is committing each transaction when the flow terminates (Despite commit count being 50), this potentially wont give us the performance characteristics we require.
I appreciate I could test all this stuff myself but I was just looking to see if anyone knew it offhand.
If possible I'd love one of the Hursley guys to give 'the definitive guide to what Commit Count does and doesnt do' - What's the chance?
[/quote] |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Fri Dec 05, 2014 12:56 pm Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
| Sorry to bring up a old thread but my question is very relevant. If i set the commit count to say 3 and additional instances greates than 0. Is the commit count kept track off for each thread in the additional instance seperately? |
|
| Back to top |
|
|
| McueMart |
| Posted: Mon Dec 08, 2014 1:52 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Commit count is at a thread level (im 99.9% certain!) |
|
| 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
|
|
|
|
