RE: Preferred method to access databases from Servlets

Um... I donno... my eyes always glaze over immediately whenever I see that
much text.  It should be really easy but I see my directions with the
distribution where pretty poor (I think I was just really happy to be done
with it).  Assuming v4r4 and JDK 1.1.x, do this:

1) get the zip file and unzip it somewhere on your PC
2) create a directory somewhere on your 400 called COMMON (I used this as a
package name throughout - case is important).
3) ftp all the .class files to the 400 into that directory
4) all you will need in your classpath is the directory where the COMMON
directory is.
     for example, I create /home/cujo/COMMON and put the class files in
there
     and my classpath should be '/home/cujo'
5) programs should run with something like this:  java COMMON.SimpleJDBC

Hope that helps.

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"




"Patrick L Archibald" <Patrick.Archibald@HOMETELCO.COM>@midrange.com on
09/20/2000 01:33:08 PM

Please respond to JAVA400-L@midrange.com

Sent by:  owner-java400-l@midrange.com


To:   <JAVA400-L@midrange.com>
cc:
Subject:  RE: Preferred method to access databases from Servlets



Richard

I want to try out your code from your COMMON presentation
but I'm new to Java and don't have a grasp on the classpath
variable yet. Here is what is in my CLASSPATH environment
variable for my system.  I'm at V4R4M0.  What am I missing?

                         Display Environment Var (*SYS)

 Name  . . . . . . . . . :   CLASSPATH


 Value . . . . . . . . . :
'/QIBM/ProdData/IBMWebAS/lib/ibmwebas.jar:/QIBM/Pro
dData/IBMWebAS/lib/jst.jar:/QIBM/ProdData/IBMWebAS/lib/jsdk.jar:/QIBM/ProdData/I

BMWebAS/lib/x509v1.jar:/QIBM/ProdData/IBMWebAS/lib:/QIBM/ProdData/IBMWebAS/lib/d

atabeans.jar:/QIBM/ProdData/IBMWebAS/web/classes/ibmjbrt.jar:/QIBM/ProdData/IBMW

ebAS/samples:/QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar:/QIBM/ProdData/HTTP/

Public/jt400/lib/jt400Servlet.jar:/QIBM/ProdData/HTTP/Public/jt400/lib/jt400Acce

ss.zip:/java'


Thanx, PLA


-----Original Message-----
From: owner-java400-l@midrange.com
[mailto:owner-java400-l@midrange.com]On Behalf Of cujo@us.ibm.com
Sent: Monday, September 18, 2000 6:12 PM
To: JAVA400-L@midrange.com
Subject: RE: Preferred method to access databases from Servlets



I did a COMMON presentation last Spring on JDBC performance in which the
final topic was JDBC object caching.  The code and presentation can be
downloaded from http://www.as400.ibm.com/developer/jdbc/index.html.  I will
be at Fall COMMON as well and would be happy to talk with anyone face to
face while there about things they are working on.

I have an article on JDBC object caching coming out in AS/400 Magazine in a
month or two (Oct. issue I believe).  This is basically a more detailed
look at some of the stuff from the COMMON presentation.  If you have access
to the magazine, you might want to check that out.

Also, I have an article on advanced JDBC performance issues coming out in
Midrange Computing in the next month or two that might be helpful.

Finally, Java Report, Sept. 2000 issue has an article about object pooling
in general.  Jonathan Amsterdam explains how to integrate object pooling
for basically any type of Java Object (and he does it in only a 1.5 pages).
Its also worth reading.

I hope some of this info proves to be helpful.

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"




"Eyers, Daniel" <daniel.eyers@honeywell.com>@midrange.com on 09/18/2000
02:21:46 PM

Please respond to JAVA400-L@midrange.com

Sent by:  owner-java400-l@midrange.com


To:   "'JAVA400-L@midrange.com'" <JAVA400-L@midrange.com>
cc:
Subject:  RE: Preferred method to access databases from Servlets



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



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



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