Again - JDBC thin vs. thick
- From: "Carel-Jan Engel" <cjpengel.dbalert@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 15 Sep 2004 14:19:30 +0200 (CEST)
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)
===
--
//www.freelists.org/webpage/oracle-l
Other related posts:
