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.
Thanks! I could use your help! I'm operating (in this topic context) as middleware
which pools JDBC connections, each of which cache prepared statements. Customer code
uses these connections, and involves them in multi-statement, multi-resource transactions.
If there is a "TAF", is there a way *I* can shield the client code from the effects
on the prepared statements they may be in the process of using?
Appreciatively,
Joe Weinstein at BEA
Received on Thu Feb 05 2004 - 10:25:50 CST
