valutazioni - 0, GPA: 0
(
)
)
|
da questo dispositivo ha anche altre istruzioni :
Computer - HP Integrity NonStop H-Series (1.98 mb)
Computer - HP Integrity NonStop H-Series (16.73 mb)
Computer - HP Integrity NonStop H-Series (957.56 kb)
Computer - HP Integrity NonStop H-Series (2.38 mb)
Computer - HP Integrity NonStop H-Series (881.66 kb)
Computer - HP Integrity NonStop H-Series (965.62 kb)
Computer - HP Integrity NonStop H-Series (676.93 kb)
Computer - HP Integrity NonStop H-Series (393.72 kb)
Computer - HP Integrity NonStop H-Series (776.57 kb)
Facilità d'uso
Designing Single-Threaded Processes
Checkpointing Strategy
The procedure call for checkpoint A occurs when the primary process is about to
initiate a transaction but has not yet issued the BEGINTRANSACTION call. At that
point, the backup requester’s TFILE is updated to indicate that there is no current
transaction. All of the application data necessary to start the new transaction is
present in the data stack and data blocks that are copied to the backup process by the
CHECKPOINT procedure.
The procedure call for checkpoint B occurs when the primary process is about to
commit the transaction but has not yet issued the ENDTRANSACTION call. At that
point, the backup requester’s TFILE is updated to reflect the current transaction.
If the backup process is executing a single CHECKMONITOR call repeatedly, you
might want to include a program variable in the checkpointed data that serves as a
toggle switch identifying the current checkpoint (A or B); in the event of a primary-to-
backup switch, the backup process would then know immediately at what point in the
primary requester’s transaction loop the failure occurred.
When the primary fails, the CHECKMONITOR loop in the backup process passes
control to a section of takeover code. That code must first determine whether or not a
transaction was in progress when the primary failed.
Consider the effects of a primary process failure at points 1, 2, and 3 in the transaction
processing loop illustrated in Figure 2-1.
If the failure occurs at point 1, the backup process detects by the occurrence of check-
point A that the primary was about to initiate a transaction and that the transaction
either did not get started or was initiated and then aborted because of the failure.
Therefore, without further investigation, the backup (now acting as a primary) starts a
new backup process and then restarts the transaction using the checkpointed
application data.
If the failure occurs at either point 2 or 3, the backup process knows by the occurrence
of checkpoint B that the processing of a transaction was complete when the failure
occurred but does not know whether the transaction was committed or aborted. The
backup determines the outcome of the transaction by fetching the transaction’s
BEGINTRANSACTION tag value from the checkpointed data and then issuing a
RESUMETRANSACTION call containing that tag value, followed by an
ENDTRANSACTION or an ABORTTRANSACTION call.
If the transaction may have committed before the failure occurred, the
RESUMETRANSACTION call returns the error number 76 (transaction ended) in the
status variable. In this case, the backup (now acting as a primary) should call
ENDTRANSACTION. If ENDTRANSACTION returns no error, the transaction is
committed, and the application starts up a new backup process and then issues a
READ to the terminal to accept the next operator request. If ENDTRANSACTION
returns an error, the transaction is aborted, and the application starts a new backup
process and restarts the transaction using the checkpointed application data.
If the transaction was aborted, however, the RESUMETRANSACTION call returns one
of the errors 90 through 97 described in Table 2-2. In this case, the backup (now acting
HP NonStop TMF Application Programmer’s Guide— 540139-002
2- 10
...