[MQueue] IBM WMQ Transaction Recovery

.
. IBM WebSphere MQ v6.0
. Chapter 4.3 IBM MQ Transaction Recovery
.

=== Message Persistence ===
1. Persistent messages are recovered on restart, if necessary.
2. Nonpersistent messages are expressly discarded on restart.
3. Logging has performance impact.
4. DefPersistence attribute of a Queue.
5. Any Queue may store both persistent and nonpersistent messages,
　　except a Temporary Dynamic Queue

※ Non-persistent messages can be used for better performance when it is not critical for
　　messages to be able to survive a Queue Manager restart.

※ Both persistent and nonpersistent messages may be stored on the same Queue.
　The only exception to this is a Temporary Dynamic Queue which can only store
　non-persistent messages.


=== Types of Log ===
1. CIRCULAR (default) :
　- Log files viewed as a closed loop.
　- Amount of disk space required for the log does not increase with time.
　- 足夠大的Circular Log, 才能作所有的Transaction.
2. LINEAR :
　- Log files viewed as a sequence.
　- Log file never deleted BUT
　　-- Becomes inactive when it contains no entries required to restart the Queue Manager.
　　-- Can be archived when it becomes inactive.
　- Needed for media recovery.

※ Periodically, the Queue Manager performs a log checkpoint. Information about the last
　checkpoint, including its location in the log, is held in the checkpoint file, amqalchk.fil


=== Recovering Persistent Messages ===
1. If nessary, persistent messages are recovered automatically when the Queue Manager is restarted.
2. A damaged Local queue may only be detected later :
　- Reported as "object damaged".
　- Normally needs to be recovered manually.
3. In order to restart, a Queue Manager only requires :
　- Log records written since the last checkpoint.
　- Log records written by transactions that were still active at the time the Queue Manager stopped.


=== Damaged Objects and Media Recovery ===
1. WebSphere MQ objects can be marked as damaged :
　- Corrupt data in the Queue file.
　- Missing Queue file.
　- Disk failure.
2. Damaged objects can be deleted.
3. A damaged object can be re-created from a LINEAR log :
　- Known as media recovery
　- Media images of some objects are recorded automatically by the Queue manager at certain times.
　- Record the media images of a Local Queue on a regular basis using the control command rcrmqobj

※ The control command to record a media imge is rcdmqimg.
　For example, the following command will record a media image of a Local Queue :　
　# rcdmqimg -m QMgrName -t QLocal QName

※ A damaged object can be re-created by using the rcrmqobj control command.
　For example, the following command will recreate a Local Queue :
　# rcrmqobj -m QMgrName -t QLocal QName


=== Dumping the Log ===
1. Use dmpmqlog to dump a formatted version of the log.
2. Queue Manager must not be running.
3. By default, the dump commences from the head of the log.
　Optionally, the dump can commence from :
　　- The base of the log.
　　- A log record identified by a specified log sequence number (LSN).
　　- A log file identified by a specified extent number (linear logs only)
4. Log records formatted include :
　- Put and get of persistent messages.
　- Transaction events.
　- Creation, alteration, and deletion of MQ objects.


=== Syncpoint Control ===
　MQGET (customer order)
　Update DB
　MQPUT (dispatch request)
　MQPUT (delivery confirmation)
　Commit

1. Option on MQPUT and MQGET calls :
　- NO_SYNCPOINT (message is added or removed immediately)
　- SYNCPOINT (result of an MQPUT or an MQGET call only becomes visible
　　　　　　　　when the unit of work is committed.)
2. Default is platform-dependent.
3. Additional option on an MQGET call :
　- SYNCPOINT_IF_PERSISTENT (a message is only got within syncpoint control if it is persistent)

=== Compensating Transactions ===
1. MQSeries Asynchronous Model :
　　　　□□□□□□□　　　　　　　□□□□□□□□
[DB] ← □ (Write)　　□ 　　　　　　　□　　　　　　□
　　　　□　　　　　□　　　　　　　□　　　　　　□
　　　　□　　　Put □ → [q] → [Q] → □ Get　　　　□
　　　　□Syncpoint □　　　　　　　□ 　　　(Write) □→ [DB]
　　　　□　　　　　□　　　　　　　□ Syncpoint 　□　
　　　　□□□□□□□　　　　　　　□□□□□□□□
　=> [Q] → [(Get) Syncpoint (Write)] → [DB]

2. Local syncpoint participation = committed changes


=== Coordinating Local Units of Work ===
※ A Local unit of work is one in which the only resource being updated are those
　of the Queue Manager. (QM Scope)

　MQGET message from server queue
　MQPUT extra requests
　MQPUT reply message
　
　if error ...
　　MQBACK
　if OK ...
　　MQCMIT


=== Internal Coordination of Global Units of Work ===
※ A Global unit of work is one in which the resources of other resource managers
　are also being updated.

　MQBEGIN　
　MQGET message from server queue
　EXEC SQL INSERT database record
　MQPUT reply message
　
　if error ...
　　MQBACK
　if OK ...
　　MQCMIT


=== Database Coordination ===
1. Support database managers :
　- Platform with Linux, Sun solaris, AIX, HP-UX, Windows
　- Database with Oracle, DB2, Informix, Sybase
2. Restrictions :
　- An WebSphere MQ client cannot particaipate in a global unit of work. (MQBEGIN call)
　- Only one Queue Manager may participate in a global unit of work.
　- Normally, updates to WebSphere MQ and database resources must be made on the same system. (Database server may be on a different system provided it can supply an XA compliant client feature.)


=== External Coordination of Global Units of Work ===
※ Single phase commit protocol only :
1. AIX :
　- TXSeries
　- BEA Tuxedo
　- BEA WebLogic Server
　- WebSphere Application Server
2. Sun Solaris :
　- TXSeries
　- BEA Tuxedo
　- BEA WebLogic Server
　- WebSphere Application Server
3. Linux :
　- BEA Tuxedo
　- BEA WebLogic Server
　- WebSphere Application Server
4. HP-UX :
　- TXSeries
　- BEA Tuxedo
　- BEA WebLogic Server
　- WebSphere Application Server
5. Compaq NonStop Kernel :
　- TM/MP (TMF)
6. Windows :
　- TXSeries
　- BEA Tuxedo
　- BEA WebLogic Server
　- WebSphere Application Server
　- MTS/COM


=== CICS Transaction ===
1. A CICS transaction may issue MQI calls.
2. A CICS trigger monitor can start a CICS transaction when a message arrives in a Queue.
3. Only one Queue Manager can be assessed at a time from a single CICS region.
　- Using CICS with a two-phase commit protocol.

※ On AIX, HP-UX, Solaris, and Windows , there is a supplied trigger monitor which runs as a CICS transaction. The process object specifies which transaction to start.
　APPLTYPE　CICS
　APPLICID　Transaction ID
The trigger monitor performs EXEC CICS START and passes MQTMC2 as CICS data.
If the trigger monitor is started withous data, it gets the trigger messages from SYSTEM.CICS.INITIATION.QUEUE