Seem the thin client is 100% java using TTC. (Two Task Common) So you are 100% out of luck with TAF and a host of other neat OCI features sorry to get your hopes up.
Seems the thin client is about as feature rich as an early Oci7 connection yuck!
cheers
Folks, 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 10.2.0.2 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... Thx. DAVID HERRING DBA Acxiom Corporation EML dave.herring@xxxxxxxxxx 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. -- //www.freelists.org/webpage/oracle-l
-- //www.freelists.org/webpage/oracle-l
