Again - JDBC thin vs. thick

Dear all,

Sorry to get back on this topic again, but the relegious war on JDBC thin vs. thick continues here. (FYI, I'm on the thick side, though loosing weight rapidly, 11kg in 9 weeks)

From
http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm#02_05 I got this snippet:

>Which driver should I use?
>If you are writing an applet, you must use the Thin driver.
>
>If you are using a non-TCP/IP network you must use the OCI driver.
>
>Generally the Thin driver is the best choice. In most cases it is as fast
>or faster than the OCI driver (from 10.1.0), has almost exactly the same
>set of features, and is easier to administer. In a few cases the OCI
>driver has slightly better performance. The OCI driver supports a few
>Oracle features better than the Thin driver. The Thin driver is easier
to >administer since it does not require installation of the OCI C libraries. >The Thin driver will work on any machine that has a suitable Java VM, >whereas with the OCI driver you must install the proper OCI C libraries >for each machine. We recommend using the Thin driver unless you must have >one or more of the OCI only features, or until it is clear that the small >performance gain provided by the OCI driver is worth the extra effort.
>
>If you are running in the Oracle server, then you should use the Server
>Internal Driver unless you need to connect to another Oracle database
>server or to open a second session on the same server. In either of
these >cases you should use the Server Thin Driver.

I was (and still am) convinced that JDBC thin is nice for applets, but that an application server shoudl use thick.

Look at the fourth sentence of the snippet: it says 'it's easier to administer.' I do not like this subjective statement in an official Oracle FAQ. Developers here quote this and leave me with no 'official' arguments when I state that running over 100 databases on over 60 servers whith at least as many copies of tnsnames.ora plus the additional copies of Java properties files with JDBC thin connection parameters doesn't come near to 'easy to administer'. I think this FAQ suffers from tunnel-vision, just covering the local administration on the developer's PC and not even thinking about enterprise daily DBA work. Just to cope with this daily DBA work it has been decided that OID will be implemented here, to achieve a SPOT (Single Point Of Truth). I think that configuration and application should be separated, leaving the DBA-department the freedom to move a database around whenever they like, whithout the need to reconfigure an application properties file.

Mind that the Java software runs on Weblogic, on a couple of servers, so no client HW-stuff is involved except the developers' PCs, but that is their problem. I'd think that JDBC thick driver would be a smart move, but the Java community here is scared to death by the 'fact' that pulling 'C' libraries into the software stack might very well cause the JVM to crash. They claim this has happened in the past all over the world and just throw a pile of links claiming these crashes at me. This <quote> will happen at unforeseen moments, and therefore cannot be ruled out by sufficient testing </quote>.

I'm RTFM'ing, Googling, searching AskTom, whatever, but cannot find a valid link that supports 'an' opinion that using 'thick' is the way to go when running Java stuff on a server. Can anyone provide me some links, or tell me that I'm wrong and actually 'thin' is the way to go?

Regards, Carel-Jan

===
If you think education is expensive, try ignorance. (Derek Bok) ===

--
http://www.freelists.org/webpage/oracle-l