Caché System Administration Guide - InterSystems Documentation

In addition to the new values of 900 and 600, the journal contains the pre-transaction values of 1000
and 500. In the event that a rollback is required before the transaction is committed, these old values
are used.
When a system crash occurs, rollback happens automatically. First, recovery via the two-phase write
protocol restores the internal consistency of the database. Next, all incomplete transactions (those that
began but were never committed) are rolled back.
10.4.2 Transactions and Locking
You use the Lock command in Caché applications to protect against simultaneous access to data.
For example, an application might contain the following steps:
TSTART
//begin transaction
Lock +^SAVINGS(ACCOUNT,"BALANCE") //lock record
Set ^SAVINGS(ACCOUNT,"BALANCE") = ^SAVINGS(ACCOUNT,"BALANCE") - 100
Lock -^SAVINGS(ACCOUNT,"BALANCE") //unlock record
Lock +^CHECKING(ACCOUNT,"BALANCE") //lock record
Set ^CHECKING(ACCOUNT,"BALANCE") = ^CHECKING(ACCOUNT,"BALANCE") + 100
Lock -^CHECKING(ACCOUNT,"BALANCE") //unlock record
TCOMMIT
The value of SAVINGS becomes unavailable to other processes when it is locked, and available again
as soon as it is unlocked.
Now suppose that a transaction fails as the application is updating CHECKING. Transaction rollback
occurs, restoring SAVINGS to its pre-transaction value. But, what if between the instant the application
unlocks SAVINGS and transaction rollback completes, another process accesses SAVINGS If it
examines this value, it may carry out further processing that is erroneous. Worse yet, if it changes this
value, rollback cannot occur.
Caché automatically avoids this problem by deferring any unlocks within a transaction until the
transaction is committed or rolled back. Within the transaction, the data appears to be unlocked, permitting
a subsequent lock of the same value in the same transaction to work correctly. Outside the
transaction, however, the data remains locked.
10.4.3 Global Journaling
Logical Data Protection
Global journaling preserves changes in the database since the last backup. While a backup is the cornerstone
of physical recovery, it is not the complete answer. Restoring the database from a backup
makes the contents of the database current as of the time the backup was completed. Typically, this is
a long time (at least a number of hours) before the point at which physical integrity was lost. What
happens to all the database changes that occurred since then The answer lies with journaling.
Each computer running Caché keeps a journal. The journal is a file that keeps a time-sequenced log
of changes that have been made to the database since the last backup. The process is redundant and
Caché System Administration Guide 103