From: gjb@fig.citib.com (Greg Brail)
Newsgroups: comp.databases
Subject: Re: Hot Standby DBMS's
Date: 25 Aug 92 20:11:50 GMT
Organization: Citibank IBISM

In article <BtB7Lo.26u@world.std.com> edwards@world.std.com (Jonathan Edwards) writes:
>In article <1992Aug20.192538.17842@cbnewsl.cb.att.com> sdo@cbnewsl.cb.att.com (scott.orshan) writes:
>>This means that a bank's application, which knows how to debit your
>>bank account, and a stock brokerage application, which knows how to
>>buy shares of stock, can be linked in a distributed transaction
>>such that the stock purchase and the debit occur together.  Without
>>this capability, the stock brokerage has to generate a batch EFT
>>transaction to the bank that may bounce, but the stock has already
>>been purchased.
>>
>As an implementor of just such EFT systems, I can assure you that this
>would be unthinkable. Distributed transactions have the well-known effect
>of eroding system autonomy. If one system goes down, it can leave various
>locks on the other which can not be broken until the system is recovered
>(unless they are forcibly broken, resulting in possible inconsistent databases
>requiring manual resolution).

There may well be philosophical aspects to "system autonomy" that make
it a good thing, but distributed transactions as implemented by Tuxedo
or Encina do not cause the problems you describe above. If, for argument's
sake, we describe a "physical transaction" as an atomic action managed
by the transaction management system, then we will begin the physical
transaction, debit the account, and send a message asking the brokerage
application to purchase the stock. We wait for the brokerage to respond --
if something goes wrong, we abort the whole transaction and the bank
debit (along with whatever may have happened of the stock purchase) are
completely undone. No locks need be forcibly broken.

Such systems as Tuxedo and Encina can implement a distributed system this
way. As Mr. Orshan describes, the alternative is to send an asyncronous
message to the brokerage and write enough recovery logic into the
bank application so it can roll back the work when the brokerage
transaction fails.

Of course, a complete financial transaction (such as an EFT transfer)
may well encompass several physical transactions. In this case, the
application still must be able to undo any failed step, but there are
fewer steps to keep track of.

>>These facilities allow for a hot standby system or network to exist
>>far away, with all service requests done both locally, and also queued
>>for processing at the backup site. (I'm talking about high level
>>application requests: DEBIT, RESERVE-ROOM, etc., not physical database
>>operations.)

Again, doing this by placing items in a queue makes recovery more
difficult than using synchronous RPCs, although it's still doable.

>Again, I must say that this is impractical. Unless the system is
>trivial, or is single-threaded, you can not
>guarantee the same application execution history for a copy of the input 
>stream, due to timing differences in race conditions.

If you can update all the copies of the database in one atomic, physical
transaction, timing differences don't matter. That's why databases have
things like two-phase locking.

>>By architecting the backup system so that it uses a different DBMS,
>>or even a different implementation of the application, it is more
>>likely that one system will be able to continue processing if the other
>>is stopped by a bug.

This is certainly possible using existing distributed transaction processing
systems, and is certainly a good idea. Also keep in mind that some types
of storage systems are better at some tasks than others. An ISAM-like file
system may outperform a relational database for random access lookups,
but will not necessarily support ad-hoc queries via SQL. So one can use the
ISAM files for most day-to-day operations, and the RDBMS as a backup.

				greg
-- 
Greg Brail ------------------ Citibank -------------------- gjb@fig.citib.com
lose (lOOz) v. 1. a. To be unable to find; mislay. b. To incur the 
deprivation of, as by negligence or accident. 2. To be unable to maintain,
sustain, or keep. 3. The most commonly misspelled word on Usenet.
Xref: sparky comp.databases:6423 comp.databases.informix:1829