Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: yipeee!

Re: yipeee!

From: Holger Baer <holger.baer_at_science-computing.de>
Date: Thu, 05 Feb 2004 17:22:56 +0100
Message-ID: <bvtql0$n0p$1@news.BelWue.DE>


Daniel Morgan wrote:

> Joe Weinstein wrote:
> 

>> Yep. Also, I really don't want to sound like I'm picking only on Oracle,
>> because I complain about other DBMSes too. Oracle's TAF fooled a number
>> of customers into believing it really was Transparent Application
>> Failover,
>> but it seems to be so only for certain mostly-idle clients. The reason I
>> say this is because while there is no data loss during a failover, nor
>> even any transactional context (locks), what is lost is any
>> *computational*
>> context that the client may be relying on if it was actually doing
>> something when the failover occurred. For instance, most cursor context
>> is lost. Java clients that may have created and are re-using Prepared
>> Statements will find that all those prepared statements are now defunct,
>> and must be recreated before the client can even retry what they were
>> doing.
>> This generally means returning to the line of code right after
>> obtaining the
>> original connection. Having the connection automatically failover to an
>> appropriate backup DBMS is certainly valuable, but calling it "TAF" was
>> 'aiming high' in the marketing department, IMHO.
>> Joe
> 
> 
>  From the client's standpoint it is completely transparent which is the 
> origin of the name.
> 
> Perhaps you need to come take the class I teach on RAC.
> 

I guess it's a question how you define 'completely transparent'. Of course, the client has to do nothing but sit there and wait until the connection is failed over. However, one might argue that just having lost my running transaction (insert, update, delete) and all my package states is all that transparent.
But I'm still impressed how the new node is able to pick up a running query and continue at the same point where the failover occured - since a resultset per definition has no order (except when specified) I'm still wondering how the node I failed over to is able to bypass that restriction. It was a question the teacher of my RAC course couldn't quite answer, but then maybe he just knew so much more of the internal mechanics that he needn't to wonder ;-)

Cheer up, that cast on your leg won't last forever ;-)

Holger Received on Thu Feb 05 2004 - 10:22:56 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US