MQSeries.net :: View topic

smdavies99 · Posted: Wed Jun 28, 2006 2:56 pm Post subject:

One of the advantages of Broker Variables can be to reduce contention on a Database table which is being used for things like message counts.
However, one of the key missing features that you get with DB tables is locking so that with the appropriate SQL statement you can be sure that the count is accurate which actually gives rise to the contention you are trying to avoid. A Catch 22 situation.

In one application I am working on, we have found that in order to squeeze the last drop of performance out of a broker we need to run several additional instances (at least 3) of the main validation flow. Naturally, using these additional instances does give rise to a lot of contention on the row that holds the message count which is updated by the message flows.
If we turn on the message counts, we can get approx 45 messages processed per second.
If the counts are off then the message rate almost doubles.

So, we are looking at alternative methods of maintaining accurate message counts in the database but reducing the DB row locking contention.
We have looked at the use fo broker vairables but there is a window where one instance could decide that the message count db needed updating and whilst it did so, another instance updated the count.

The message counts are needed as they form part of the SLA to the end user and have to be available in the DB.
There are several different messge flows that update different counts in the DB and stats are read from these tables frequently throuoght the day (24/7)

Has any MQSeries.net reader/guru/genius faced this sort of problem and if so what methods did you use to solve it.

Stephen Davies
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.