WebSphere Information Integrator Q Replication: Fast Track Implementation Scenarios

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.