>> <kuassi.men..._at_gmail.com> wrote in message>>>> news:eb45f9a5-352a-447c-b48e-91a394027397_at_u6g2000prc.googlegroups.com...>>>> > On May 21, 2:20 pm, "jim. dot scuba dot kennedy at gee male dot com">> > <jim.scuba.kenn..._at_gmail.com> wrote:>> >> Does anyone have any experience using Oracle's JDBC ICC (implicit>> >> connections cache) with RAC? We are on 10G. What I am looking for is>> >> if anyone is using this and their overall experience. Good bad, etc.>> >> Thanks,>> >> Jim Kennedy>>>> > Hi,>>>> > I am the Oracle JDBC product manager, not a customer.>> > I don't have permission to give names but there are happy customers>> > using ICC with RAC as well as Fast Connection Failover and Runtime>> > Connection Load Balancing.>> > Fwiw, my blog entry>> >http://db360.blogspot.com/2007/01/is-your-java-application-failoverpr...,>> > gives a summary of how it works and how to enable it.>>>> > Kuassi>> > - bloghttp://db360.blogspot.com>> > - bookhttp://www.amazon.com/exec/obidos/ASIN/1555583296>> > -http://www.savedarfur.org/content>>>> Thanks. If you know of any customers that would be willing to provide>> feedback to me directly - I would not diseminate the information >> elsewhere ->> please have them contact me. jimk at snapnames dot com. We have been>> struggling with a non-rac related isse with the thin jdbc driver for a>> couple of years on a known issue. (create a type in schema A, grant >> execute>> on type to schema B. Create a synonym in schema B for the type defined >> in>> schema A. The JDBC thin driver does not handle this case. It turns out >> the>> 11g jdbc driver finally does, but Oracle recommends not using it because >> of>> a sever memory leak. Subsequently, we have had to write a lot of code to>> get around this issue and the QA manager is gun shy with some Oracle>> products. Which has lead me to my assignment to get some feedback from>> other customers. (not to be made public, to be kept in confidence) The >> QA>> manager wants to know if anyone actually uses this in production and >> wants>> to get feed back from them.>>>> I know I have rambled a bit. I have booked marked your site and am >> keeping>> a copy of your reply for reference.>> Thanks,>> Jim Kennedy

>
> Jim,
>
> Will do.
>
> There is no known memory leak with 11g JDBC-Thin; The recommendation
> is to use full/complete schema name instead of synonym becoz it takes
> a couple of round trips to get the complete information from the
> server.
>
> Kuassi

I don't have the metalink doc id with me, but when our other dba was
researching using the 11G jdbc thin driver he came across the doc. on it.
(we are using 10G as the server not 11G as the server) (short on details,
it was related to an SR with a creation date of around the end of April).
When he asked the Oracle support person about it they recommended to NOT use
the 11g jdbc thin driver because of a known memory leak.(maybe there isn't
maybe there is)

You have to add the schema in front of the type because it doesn't work if
you don't. It is a bug that has been there at lease pre 11G JDBC driver. (I
think we did confirm that it was fixed in 11G) Yes, it may be faster during
the describe to have the schema prefixed to the object type, but it should
not be required. It is not required if I do it from a tool like sqlplus for
example. (assuming proper rights and synonym creation etc.) I know this is
going to sound silly, but it would be a major code rewrite to change all the
Java objects to use an schema prefix (for a schema other than the one they
are connecting to.) Management does not want to spend the large cost to
rewrite and retest to accomadate the schema prefix when the question is "Why
doesn't Oracle fix something that should work?" (This is a known issue.)

Not trying to bitch ; just giving you customer feed back because I think it
would be helpful to Oracle. I do like the product and have had excellent
experiences with it. I have used the db since version 6 and have had some
very positive customer support experiences.
Thanks,
Jim Kennedy
Received on Fri May 23 2008 - 18:39:17 CDT