JDBC or ODBC?

I am in the interesting position of having to choose between using an ODBC or
JDBC connection for a high traffic site. We can develop on either
environment though I prefer the Java based one. Database connectivity to our
SQL 2000 server is our number one priority. Does anybody know which offers
the greatest performance and stability or at the very least point me in the
right direction?
PJ wrote:
> I am in the interesting position of having to choose between using an ODBC or
> JDBC connection for a high traffic site. We can develop on either
> environment though I prefer the Java based one. Database connectivity to our
> SQL 2000 server is our number one priority. Does anybody know which offers
> the greatest performance and stability or at the very least point me in the
> right direction?
For stability and support, you want JDBC. Performance should be a wash at least,
and unless you have reliability, you usually don't have anything. The JDBC-ODBC
bridge is notably buggy and unsupported. JDBC performance will come from pooling
and re-using open connections and similarly caching Prepared statements, and
managing any transactional work to single user-invokes (Ie: not holding locks
until a user application sends a second message). Primarily, performance will
come by doing as much of the DBMS-related work in the DBMS where the data is.
Write and use big fancy stored procedures. Always do all you can to avoid
shipping huge wads of raw data out of the DBMS to be processed.
Good luck,
Joe Weinstein at BEA Systems
|||Thanks for the reply!
To clarify, we are choosing between a server that sits on top of Windows
2000 Server that can use ODBC directly with SQL 2000, or a new version of the
same server that sits on top of a Java platform and uses JDBC (Type 4).
Either way we will not be using a bridge. Our concern is the performance
implication directly related to the database access interface. How does JDBC
compare with ODBC in this situation? Are there any reliability or
performance implications we need to consider? Thanks!
|||PJ wrote:

> Thanks for the reply!
> To clarify, we are choosing between a server that sits on top of Windows
> 2000 Server that can use ODBC directly with SQL 2000, or a new version of the
> same server that sits on top of a Java platform and uses JDBC (Type 4).
> Either way we will not be using a bridge. Our concern is the performance
> implication directly related to the database access interface. How does JDBC
> compare with ODBC in this situation? Are there any reliability or
> performance implications we need to consider? Thanks!
OK, then I don't have the data. The server vendor may... Many other factors
may contribute to which product is overall better. There may be a stability
reason for the vendor making a Java version (besides the ease of making one
such for all platforms).
joe
|||I agree with Joe in the most part. From my years of experience with db
systems and apis, the API/interface used to access the database is usually
not the performance bottleneck. The biggest problem is usually the devs
not understanding the most efficient means of doing what they need to do
with the target db. For example they select * from table instead of using
where clause to limit records, etc...
But if it came down to it, I bet I could beat slightly performance of JDBC
code with ODBC code (with alot of extra work). The reason for this is ODBC
is accessable from C++ directly, and you can pass buffers directly from C++
to ODBC API without any conversion. So the data goes straight from my C++
buffer to the driver to the wire and back. With JDBC I have to call some
setter or getter and then this has to translate from UNICODE Java string to
bytes before sending over wire, etc...
But at the end of the day, I will spent 4 weeks writing a bunch of C++ code
to get a few extra milliseconds of perf. I could have written the whole app
in JDBC in a few days, etc... The same argument goes for use VB6 or VB.NET
to SQL, it's very easy to write the code, the perf is not that much worse
than C++, why not use it, etc...
So as the saying goes, don't optimize too early. (G)
Matt Neerincx [MSFT]
This posting is provided "AS IS", with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"Joe Weinstein" <joeNOSPAM@.bea.com> wrote in message
news:%23eHmr2YrFHA.1032@.TK2MSFTNGP12.phx.gbl...
>
> PJ wrote:
>
> OK, then I don't have the data. The server vendor may... Many other
> factors
> may contribute to which product is overall better. There may be a
> stability
> reason for the vendor making a Java version (besides the ease of making
> one
> such for all platforms).
> joe
>