Re: forcing native access with websphere and toolbox -- JAVA400-L

We haven't targeted performance yet- it is coming soon. We are happy with ODBC performance via SQL and stored procedures to the 400 from PC client apps. So far, we are dissapointed (and surprised) with initial performance of an applet which communicates with servlets running under WebSphere (via the HTTP server) which in turn use JDBC access. We have not yet pinpointed the bottleneck(s) so it is too early to say where the problem lies. I don't doubt that record level access is faster, but it doesn't suit our particular requirements. On the other hand, we also have some servlets which respond with HTTP/JSP and access the database with the toolbox JDBC drivers to execute stored procedures, and except for the first time they are run after starting up, the performance is fine. Anyway we have a lot of hunting to do. If we are not happy with the end result, then Rochester has some work to do IMHO. I expect performance via JDBC to be at least as good as with ODBC on the 400 (actually, better if I use the native DB2 drivers directly on the box), especially if Rochester wants to market the 400 as THE java server. Anyway, I have yet to crack open the V4R4 performance guide, but it has chapters on each of the components involved in our system.

Luther

----- Original Message -----

From: Alex Garrison

To: JAVA400-L@midrange.com

Sent: Thursday, 11 November 1999 14:19

Subject: Re: forcing native access with websphere and toolbox

A personal comment on jdbc:

We used the jdbc drivers from websphere on the as/400 (both toolbox and native) for about 17 months. To make a long story short - the performance just isnt there.

I know others have had a great experience with jdbc. We brought in several such lucky folks as consultants to learn from their experiences. Some techniques do help - stored procedures, analyzing sql optimizer diagnostics, etc. Bottom line, though, is that we get much better (like over 50%) performance using record-level i/o. I know we lose portability by going to record-level access, but a portable slow-running servlet is just no good to us. We really just got to the point where we had no choice.

I am not saying everyone should dump jdbc for record-level i/o, but I have a feeling there are others out there with the same experience we had. Anyone else go from jdbc to record-level i/o or are unhappy with jdbc performance in websphere on an as/400?

----- Original Message -----

From: Luther Ananda Miller

To: JAVA400-L@midrange.com

Sent: Thursday, November 11, 1999 4:38 AM

Subject: Re: forcing native access with websphere and toolbox

If you use JDBC, you can use the toolbox JDBC drivers to connect to the AS/400 from anywhere. If you are running your servlets on the AS/400, you can configure your servlet to use the native DB2 JDBC drivers instead of the toolbox drivers for faster access. (Not sure how it compares to record level access- I imagine record level performs faster). Another advtange of JDBC is that your servlet will likely run on any java platform and connect to any database, depending on the SQL that you use instead.

Interesting about how you must connect as QTMHHTTP to bypass TCP/IP on the 400 -- I did not know that.

Luther

----- Original Message -----

From: Alex Garrison

To: JAVA400-L@midrange.com

Sent: Wednesday, 10 November 1999 21:36

Subject: forcing native access with websphere and toolbox

Tip of the day: IBM Java Toolbox Record Level I/O from Servlets

...