RE: Preferred method to access databases from Servlets

["Eyers, Daniel" <daniel.eyers@xxxxxxxxxxxxx>]

Richard, 

Thanks for that weel-thought out response... It helps those of us trying to
make decisions about the appropriate direction to go.  I agree that SQL is
the current direction of the industry and is certainly a major consideration
for any shop just starting down the Java road.

You mentioned doing some caching to improve SQL performance.  Is there a FAQ
or white paper that addresses this issue?  We are getting to the point where
we need to start looking at performance and would appreciate some direction.

BTW, love your signature line.  EAP is one of my favorite 19th century
authors.

dan
Honeywell International

-----Original Message-----
From: cujo@us.ibm.com [mailto:cujo@us.ibm.com]
Sent: Monday, September 18, 2000 10:26 AM
To: JAVA400-L@midrange.com
Subject: RE: Preferred method to access databases from Servlets



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
+---
+---
| 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
+---