jdbc thin and TAF connections

From: Herring Dave - dherri <Dave.Herring_at_acxiom.com>
Date: Wed, 20 Apr 2011 15:22:07 +0000
Message-ID: <BD475CE0B3EE894DA0CAB36CE2F7DEB4050DB471_at_LITIGMBCRP01.Corp.Acxiom.net>


Just a warning up front on this question, I'm still only drinking java and not coding in it nor having little to no understanding of how it's related to the db.

That said, we've got a 4-node RAC on with thousands of incoming jdbc thin connections coming in per hour. The app team has sent me their connect strings and I see they include "...(FAILOVER = ON)...(FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC))" and I've verified this in what's displayed in the listener logs. Yet checking FAILOVER_TYPE and FAILOVER_METHOD in GV$SESSION I see only "NONE".

MOS note 297490.1 says that the 10g jdbc/thin driver doesn't support TAF, so my assumption is this is why the physical connection drops all failover definitions for jdbc. Correct? If so, then is the best option to define this for the Oracle services they're connecting to via srvctl? Currently we have:

% srvctl config service -d $db_unique_name -a service1 PREF: inst1 inst2 AVAIL: TAF: NONE service2 PREF: inst3 inst4 AVAIL: TAF: NONE

I assume that if I give the Oracle service any definition that jdbc connections will still pick them up, even if all TAF definitions are ignored on their connect string. Correct? I'd test this to get my answer but I don't have a test system and due to my ignorance with java, I couldn't get a test jdbc connection working even after using MOS doc 433827.1. Now if this was COBOL-72...


Acxiom Corporation

EML   dave.herring_at_acxiom.com
TEL    630.944.4762
MBL   630.430.5988 

1501 Opus Pl, Downers Grove, IL 60515, USA WWW.ACXIOM.COM The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you.
Received on Wed Apr 20 2011 - 10:22:07 CDT

Original text of this message