WebSphere MQ is the means of transporting messages in both Classic
event publishing and Classic replication.
About this task
A
send queue is used to transport data to consuming applications or Q Apply.
A restart queue is used for data recovery tasks. An administration
queue is used in Classic replication for administrative tasks for change
capture. In your configuration, you must specify the name of the WebSphere®® MQ
queue manager that will manage the send queues, the name of the restart queue,
and (for Classic replication) the name of the administration queue.
You
can also adopt the File Manager option as a publishing target for event publishing.
See the topic about configuring publication to queues or files.
Procedure
To specify the WebSphere MQ objects that you want
to use for change capture:
- Open the Configure Publishing Target wizard. To open the wizard, in the Database Explorer right-click the capture-side
data server that contains the metadata catalogs and control files.
If you are running the wizard for the first time, the Specify Publishing
Target page appears. Subsequently, the Configure Publishing Target page appears.
If the latter page appears, skip the next step.
- Select WebSphere MQ Series.
- In the wizard, specify the names of the following objects for the
publishing target:
- 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.