Newsgroups: comp.databases
Subject: Re: Hot Standby DBMS's
From: briand@anasaz (Brian Douglass)
Date: 23 Aug 92 03:11:55 GMT
Organization: Anasazi, Inc.  Phoenix, Az

In article <BtDxM2.HJn@world.std.com> edwards@world.std.com (Jonathan Edwards) writes:
>In article <1992Aug21.073707.6235@anasaz> briand@anasaz (Brian Douglass) writes:
>>The two systems are not in lock step.  The above transaction would arrive
>>at machine 1 as a DEPOSIT transaction and would be processed by the
>>DEPOSIT process.  The very same transaction would be routed to machine 2
>>for the same processing.  There is no need the individual DEPOSIT processes
>>to even know about each other.  The coordination that does have to take
>>place is that machine 2 completes the transaction successfully.  If it
>>doesn't, then this transaction remains open in a log on machine 1.  It does
>>NOT affect the consistency of the data on machine 1.  Machine 1 is just
>>storing up transactions that are uncompleted on machine 2.  At this point
>>it should be programatic to insure that when machine 2 does ressurect, it
>>does catchup with machine 1, and all transactions are processed singularly
>>by machine 2.
>>
>I am talking about inconsistency between the two databases, not within them.
>It is an elementary fact that complex multithreaded systems are not
>deterministic. Just reproducing the input-transaction stream on another
>system will NOT GIVE YOU THE SAME RESULTS. I used the example of two operators
>requesting an update on the same record. One wins, but not necessarily the
>same one on both systems. Unless you add special application code to resolve
>this, there will be an inconsistency between the databases. But hey, we don't
>even need this. What about timestamps placed inthe database? These will be
>different on the two systems, leading to inconsistencies (the two databases
>are NOT EQUAL).
>Duplexing inputs is simply not a general approach to data replication.
>Thank you for your comments. Goodbye.

Testy? Tsk, tsk.  Back to the discussion.

In your example you talk of two operators updating the same record.  Fine,
lets work with this. Take one person depositing to an account, another person
debiting the same account.  If by chance the debit hits before the deposit,
the average balance drops below a threshold and the account gets a service
charge.  Not desired.  Obviously in the same system, if the deposit is first, 
it obtains the locks on the records and commits its work first.  Then the 
debit occurs.

No problems here.

So what do we do about remote backup?  Before the deposit releases its
locks (commit) it dispatches the same transaction it just did to the remote
system within a Remote transaction.  That is it goes to a transaction
called Remote, who logs it, and once logged it informs the TM of its
success.  With success, the deposit and the remote transactions are rolled
forward, if not, they both get rolled back.  You could also make the call
to the Remote transaction a Lazy commit, that is the deposit doesn't care
(dangerous, but possible) what the result of the loggin is.  And now, with the 
record unlocked, the debit transaction can proceed and repeat the Remote
call.

The Remote transaction not only logs the transaction, but dispatches it to
the remote system as an asynchronous call.  Once a reply of success is
returned, the log is noted as to the success.  If failure, the item remains
in an open state.  A watch deamon can keep track of the status of the
remote system (which could be across the country or across the room), and
can flag whether or not to dispatch qued transactions.

Although the application, DBMS and TM are multithreaded, all transactions
do go through the TM and its Resource processes, and therefore can be
controlled within a transactional statement.  In particular, the use of
nested transactions and RPC (two strong points of Encina) make implementing
this programmatic solution (yes, this does take special coding like Mr. Edwards 
suggested) easier, but still within the DTP model.  With products like /Q for
Tuxedo, you get a truer message passing approach to the replicated database
issue.

I'm not saying this the best/only/ideal approach to a replicated
database/high availability system, but it does work and with existing
technology.  There's nothing exotic here.  

And I'll say it again.  Someday TMs and DBMS will give us this ability
automatically, in the meantime, all solutions are welcome.

-- 
"... For I have sworn upon the alter of god, eternal hostility against
every form of tyranny over the mind of man."  Thomas Jefferson
Brian Douglass		briand@anasazi.com 	602-870-3330 X657
Newsgroups: comp.databases