Re: TAF and FCF together ?

kuassi.mensah_at_gmail.com wrote:
> Joe,
>
> See elements of response inline
>
> joeNOSPAM_at_BEA.com wrote:
> > Hi Kuassi, what I'm looking for is a JDBC-specific list of
> > clear best-practices and limitations that describe what
> > a programmer needs to do to make TAF and the Oracle
> > JDBC driver work together.
> >
> > 1 - That document seems to state that some queries will
> > *not* survive failover, whether with a delay or not. Is this
> > true?
>
> Yes, TAF will not always successfully restart a query in progress. It
> reopens the cursors and attempts to discard rows already returned. In
> order to achieve that, it performs a chekcsum of to-be-discarded rows
> and compares that checksum against a checksum for the rows already
> returned. If the checksums are different, TAF knows the discarded rows
> are not the same as the rows already returned. In such a case, it will
> not resume returning rows and returns an error. Checksum discrepancies
> are more likely to happen with replica databases which are not
> block-for-block identical.

Kuassi, thank you very much. Your actual knowledge of the topic is invaluable.

So, what will make DBMSes likely to be non-identical? For instance, I suspect there is a timing issue for TAF failover. If an application has paused (such as being one of many threads waiting to run in an application server) when the DBMS failure occurs, I am wondering if it's connection failover and repositioning of it's cursor will happen only
when the application makes it's next use of the connection. Is that true? If so, there may be other application instances who get going sooner after the failover, and if any of these make any changes to the data involved in the query, our first application's query will likely fail,
correct? In fact, even if TAF endeavours to reposition all the application
cursors immediately on failover, it the application has 200 connections all being operated on independently by as many threads (maybe in several JVMs), I'm guessing that it is unavoidable that TAF may allow some of these threads to continue before others, and if any of these change the data, other threads doing a (re)query of the data will fail.

> > 2 - If I am in a transaction during a transparent failover,
> > what behavior will the Oracle driver exhibit that informs
> > me to roll back my transaction?
>
> JDBC is just a conduit b/w the RDBMS and TAF. (i) Upon node/instance
> failure, the connection is dead and all in-flight transactions are
> automatically rolled-back by the RDBMS. (ii) The JDBC Connection is
> failed/switched over by TAF. (iii) TAF issues an exception. (iv) TAF
> requires an ACK. (v) The application rolls back the transaction (which
> can be see as an ACK to TAF) and replays the transaction.

The standard JDBC objects do not return any exception (due to the failure/failover per se). It is only the callback that notifies the application,
and the application must rollback/redo the transaction. If the application is multi-threaded, and the callback is being processed by and administrator thread, and the user thread is in the midst of any possible JDBC call to the Oracle driver, does the Oracle driver (it's internal synchronization etc) always allow the callback thread to interrupt the user thread's JDBC operation and/or call a rollback on the connection? The reason I ask is because I have seen deadlocks on driver-internal locks when one user thread is doing it's JDBC and another thread is trying to do management stuff like rollbacks, closing JDBC objects etc.

> > 3 - If I have a set of PreparedStatements in my application
> > that I am continually re-using, will the failover ever affect
> > them and/or the DBMS cursors on which they depend?
>
> To my knowledge, PreparedStatement and their cursor are
> re-openned/executed. However If the application uses any stored
> procedures (i.e., CallableStatement), then the state of those
> procedures is lost after failover.

Thanks. So prepared or callable statements that use stored procedures will throw exceptions, and must be closed and replaced. Prepared statements that execute plain SQL should always survive, correct?

Joe Weinstein at BEA Systems Received on Tue Sep 19 2006 - 10:06:22 CDT