Great minds . . .
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, October 11, 2012 6:22 AM
To: Midrange Systems Technical Discussion
Subject: Re: Connectivity
Gotta love it when the authors of both solutions agree.
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
Kendallville, IN 46755
From: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 10/11/2012 01:53 AM
Subject: Re: Connectivity
Sent by: midrange-l-bounces@xxxxxxxxxxxx
I would say the performance depends on how many users will use it
simultaneously, and how often the SQL code is used.
For a lone user who sits and uses JDBC all day long, I'd say the two
approaches will have nearly identical performance.
For many simultaneous users, ARDGATE will win hands down because it runs
in a Java application server, so one copy of the JVM is all you need,
that drastically reduces the needed resources.
For a program that's not run so frequently, or is run by a single user,
JDBCR4 will win because you don't have to set up and run an application
server that sits in the background and gets used only infrequently.
Luis.... both solutions are free. Give them a try and see what you
think. Once you have, let me know if you agree with my analysis.
On 10/11/2012 12:46 AM, D*B wrote:
Just curious, How would you rate ArdGate's performance versus JDBCR4's?
comparing ArdGate to JDBCR4 both are using JDBC, so the performance of
remote database and network should be rather close to each other.
there are some diffrences:
ArdGate is using a DB2 exit (*ARDPGM) with some overhead
ArdGate doesn't use any RPG to Java calls, it puts the data coming from
DB2 to a DataQ and gets the response data back from a DataQ (1
send/receive cycle per SQL Operation)
ArdGate uses one prestarted JVM for the JDBC Work, each request is
performed in a Thread of its own.
no longer needed Java Ressources are freed automatically by the garbage
JDBCR4 uses lots (n JNI calls for 1 SQL operation) of RPG to Java calls
over JNI limiting performance
JDBCR4 uses multiple JVMs, one per Job using JDBCR4 limiting scalability
of the application
The result of all this might differ for your system and requirement, but
for most constellations ArdGate should be faster and scale much better.
(the ODBC based solutions would be best from the performance perspective
from the today available solutions, but maybe somebody is writing
The STRSQL performance for select statements via ArdGate sometimes seems
to be rather slow, this is caused by DB2, pulling the complete resultset
from the remote system before showing the first records.