RE: Connectivity

Great minds . . .

-----Original Message-----
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.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





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.

-SK


On 10/11/2012 12:46 AM, D*B wrote:

<Luis>
Just curious, How would you rate ArdGate's performance versus JDBCR4's?
</Luis>

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

collector

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
DRDAGate...)

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.

Dieter