|
The issue of the performance difference between RLA and JDBC is somewhat similar to the how-long-is-a-piece-of-string discussion. I think one would be lucky to develop a pure AS/400 static SQL OLTP application that would be less than 70% slower than its RLA counterpart (I 'm talking of transaction input only - batch is an altogether different story). JDBC with all its connection pooling and caching is at least 50% slower than static SQL. Now, how significant is all this? It depends. I saw an article quite recently (was it in iSeries News?) on what IBM declared a very positive Java/400 benchmark. Of course benchmark results are always nothing but misleading, but I remember a figure of 1.5M small business transactions per hour (the HW was 840 24-way). Judging by the brief description those were really very small commercial transactions. 1.5M per hour seems quite a lot, but a few months ago I was involved in an RLA benchmark achieving 11M not so simple business transactions per hour. And this benchmark decided a huge bid! Certainly, there is nothing truly scientific about the above, but still... Please don't get me wrong, I would hate to turn this subject into another "what's better, Java or RPG" discussion, but there are situations when the difference in the order of magnitude is important. My advice would be to use RPG stored procedures for data access where possible. If you keep them simple, porting them to another platform is not going to be a big deal. Lo -----Original Message----- From: Dave Wall [mailto:dawall@us.ibm.com] Sent: 18 ?????? 2002 ?. 13:34 To: java400-l@midrange.com Subject: Re: database access - performance For what it is worth I would use JDBC. The performance difference is not as big as it used to be. Work is on going on both the client and server side to make it faster. Little effort is going toward RLA. JDBC/SQL is a standard so what you learn you can apply to other platforms. It is easier to write bad SQL code but with some experience you can make your SQL implementation almost as fast as RLA. David Wall 553-5329 AS/400 Toolbox for Java Michael Knezevic <m.knezevic@porta To: "Java/400 (E-Mail)" <java400-l@midrange.com> .de> cc: Sent by: Subject: database access - performance java400-l-admin@m idrange.com 01/17/02 10:01 AM Please respond to java400-l hello, i try myself on my first real programm for the as400. now i'm thinking about how to best access the files. what method has the best performance: record-level-access or jdbc (data access through resultset)? thanx _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l. _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l. ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________
As an Amazon Associate we earn from qualifying purchases.
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.