Joe Weinstein wrote:
>
>
> 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
Feel free to contact me off-line.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)
Received on Sun Feb 08 2004 - 13:02:50 CST
