Appendix A. WebSphere MQ overview 733
Transactional support
An application program can group a set of updates into a unit of work. These
updates are usually logically related and must all be successful for data integrity
to be preserved. If one update succeeds while another fails, data integrity is lost.
When a unit of work completes successfully, all updates made within that unit of
work are made permanent and irreversible. However, if the unit of work fails, all
updates are instead backed out. This process is sometimes called syncpoint
coordination.
򐂰 A local unit of work is one in which the only resources updated are those of
the WebSphere MQ queue manager. Here syncpoint coordination is provided
by the queue manager itself using a single-phase commit process.
򐂰 A global unit of work is one in which resources belonging to other resource
managers, such as XA-compliant databases, are also updated. Here, a
two-phase commit procedure must be used, and the unit of work can be
coordinated by the queue manager itself, or externally by another
XA-compliant transaction manager such as IBM TXSeries® or BEA Tuxedo.
For further details about WebSphere MQ, refer to WebSphere MQ System
Administration Guide, SC34-6068-02.
Q replication objects
Depending on the type of replication or publishing to be performed, various
WebSphere® MQ objects need to be defined.
The WebSphere® MQ objects required by the Q Capture and Q Apply programs
are as follows:
򐂰 Queue manager
One queue manager is required on each system.
򐂰 Send queue
This is a queue that directs data messages from a Q Capture program to a Q
Apply program or user application. In remote configurations, this is the local
definition on the source system of the receive queue on the target system.
Each send queue should be used by only one Q Capture program.
򐂰 Receive queue
This is a queue that receives data and informational messages from a Q
Capture program to a Q Apply program or user application. This is a local
queue on the target system.
734 WebSphere Information Integrator Q Replication: Fast Track Implementation Scenarios
򐂰 Administration queue
This is a queue that receives control messages from a Q Apply program or a
user application to the Q Capture program. This is a local queue on the
system where the Q Capture instance runs. There is a remote queue
definition on the system where the Q Apply program or a user application
runs, corresponding to the administration queue where the Q Capture
instance runs.
򐂰 Restart queue
This is a queue that holds a single message that tells the Q Capture program
where to start reading in the DB2® recovery log after a restart. This is a local
queue on the source system. Each Q Capture program must have its own
restart queue.
򐂰 Spill queue
This is a model queue that you define on the target system to hold transaction
messages from a Q Capture program while a target table is being loaded.
The Q Apply program creates these dynamic queues during the loading
process based on your model queue definition, and then deletes them. The
spill queue must have a specific name, IBMQREP.SPILL.MODELQ.
Figure A-1, Figure A-2, and Figure A-3 show the WebSphere MQ objects that are
required for unidirectional replication between remote servers, event publishing
between remote servers, and bidirectional or peer-to-peer replication between
two remote servers, respectively.
Note: Channels and transmission queues are not defined during Q replication
configuration, but are needed for operation and are defined in WebSphere
MQ. Dead letter queues are optional in Q replication.
Appendix A. WebSphere MQ overview 735
Figure A-1 Required for unidirectional Q replication between remote servers
736 WebSphere Information Integrator Q Replication: Fast Track Implementation Scenarios
Figure A-2 Objects required for event publishing between remote servers
Appendix A. WebSphere MQ overview 737
Figure A-3 Required for bidirectional or two-server peer-to-peer Q replication
The following considerations apply to the relationship between WebSphere MQ
objects and their corresponding definitions in Q replication.
򐂰 The objects may be defined in WebSphere MQ and Q replication in either
sequence—they both need to exist prior to operation. However, the
recommendation is to define the WebSphere MQ objects first in WebSphere
MQ before configuring them in Q replication.
򐂰 The maximum size of a message (MAX_MESSAGE_SIZE) that the Q
Capture program can put on a send queue must be equal to or less than the
WebSphere MQ Series maximum message length (MAXMSGL).
For further details, refer to IBM DB2 Information Integrator Replication and Event
Publishing Guide and Reference, SC18-7568-00.

Get WebSphere Information Integrator Q Replication: Fast Track Implementation Scenarios now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.