WebSphere® MQ
is the means of transporting messages in both Classic event publishing and
Classic replication. One message queue, called the administration queue,
is used for administrative tasks for change capture. Another message queue,
called the restart queue, is used for data recovery tasks.
About this task
You
must specify the name of the WebSphere MQ queue manager that will manage all
of the send queues, the name of the administration queue, and the name of
the restart queue in your configuration.
Procedure
To specify the WebSphere MQ objects that you want
to use for change capture:
- Open the Configure WebSphere MQ Values wizard. To open the wizard, in the Database Explorer right-click the data server
where you plan to create your publications or subscriptions. Select Configure
WebSphere MQ Values.
- In the wizard, specify the names of the following objects:
- Queue manager
- The WebSphere MQ
program that manages the queues that you will use as the restart queue, administration
queue, and send queues.
- Restart queue
- The queue that holds restart information that is required if change capture
goes into recovery mode. This queue is also called the in-doubt resolution
queue.
- Administration queue (for Classic replication only)
- A queue that receives control messages from a Q Apply program or ASNCLP.
- Specify a value in milliseconds for the commit interval. The default
is 500 milliseconds.
The commit interval specifies how often,
in milliseconds, a publication service commits transactions to WebSphere MQ.
At each interval, the publication service issues an MQCMIT call. This call
signals the WebSphere MQ
queue manager to make messages that were placed on send queues available to
the Q Apply program (in Classic replication) or other user applications (in
Classic event publishing).
All of the transactions that are grouped
within an MQCMIT call are considered to be a WebSphere MQ unit of work, or transaction.
Typically, each WebSphere MQ
transaction contains several transactions. If a transaction is large, the
publication service will not issue an MQCMIT call even if the commit interval
is reached. The publication service will commit only after the entire large
transaction is put on the send queue.
Finding the best commit interval
is a compromise between latency (the delay between the time that transactions
are committed at the source and target databases) and CPU overhead that is
associated with the commit process:
- To reduce latency, shorten the commit interval.
Transactions will be
pushed through with less delay. Reduced latency is especially important if
changes are used to trigger events (in Classic event publishing).
- To reduce CPU overhead, lengthen the commit interval.
A longer commit
interval lets you send as many transactions as possible for each WebSphere MQ
transaction. If you lengthen the commit interval, you might be limited by
the maximum depth (number of messages) for send queues and by the queue manager's
maximum uncommitted messages (MAXUMSGS) attribute. If a publication service
waits longer between commits, the publication of some transactions might be
delayed, which could increase latency.