× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Preferred method to access databases from Servlets
  • From: cujo@xxxxxxxxxx
  • Date: Mon, 18 Sep 2000 09:25:51 -0500
  • Importance: Normal


I confess that I didn't start reading this thread until the last couple
posts.  Sorry... very busy.  Please accept my apologies if I simple
re-interate some of the points made earlier.  I thought some of you might
want my take on the issue from sitting 'behind the wall'.  Eric, I do not
choose to debate you, I simply disagree.... here is my rationale:

1) Performance:  I would be skeptical that you can complete many tasks 10
to 15 times faster using record level access through Java than I can
complete them using JDBC.  You may want to investigate various object
caching issues though JDBC.  In the majority of application spaces that I
have seen, you can use effective object caching to limit the database
overhead of using SQL.

2) Simplicity:   We have a group internally working on the TPC-W benchmark.
They have been working on it for months and the performance tuning of it is
quite complex.  Myself and another member of my team wrote the vast
majority of the same benchmark using Java/JDBC in about a week or so.  We
built a couple database indexes, used *very* smart caching of JDBC objects
and had the implementation ready to go out the door.  Yes, we did it in
about a week.  When they are done, will they beat us in performance?  Yes,
they will.  But with tuning we will approach their numbers.  Their initial
estimate was that a Java based solution would be 7-40 times slower.  We
expect to be within 2x.  Now, ask youself this: which version is more
likely to have bugs in it?  Which version do you want to maintain and
modify in the future?

3) Future:  The future is SQL.  This is not an opinion of mine, this is
fact.  Everyone continuously screams for standardization of Java,
standardization in XML, etc.... yet so many people are so quick to defend
the proprietary when that is what they know.  SQL is a stardard and it will
clearly define future direction.  It will clearly be where the (vast)
majority of our effort is invested.  Make sure that you are prepared for
that.  As you mentioned, your encapsulation of database access should allow
for that, but I don't think you will be switching to use JDBC when it is
faster.  For many tasks, it will never be faster.  You will be switching
because you will not have features you need through Native IO.

There, I have said my piece.  Choose your directions.  If you are familiar
enough with Native IO to be efficient with it and convinced your future is
safe through Native IO.  You should use it.  If you choose to, you should
make sure you have provided youself the correct encapsulation to move away
from that path in the future if you need to.  If you choose the SQL/JDBC
path, you probably don't need that encapsulation... you won't be going
back.

Regards,

Richard D. Dettinger
AS/400 Java Data Access Team

"TRUE! nervous, very, very dreadfully nervous I had been and am; but why
WILL you say that I am mad?
The disease had sharpened my senses, not destroyed, not dulled them. "

- Edgar Allan Poe
"The Tell-Tale Heart"



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.