Re: Connectivity

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