RE: SQL vs "native" I/O performance

[pluta@xxxxxxxxxxxxxxxxxx]

[Paul Conte wrote:]
To get the fastest results, you need to use blocked Insert:

  Insert Into T
         n Rows
         Values( :RowArray )

and system blocking (OVRDBF command SEQONLY parameter). Be sure it's not
disabled (e.g., by trigger programs).

For realistic results, I suggest larger rows and tables, with a mixture of
data types. Avoid runs of keys. Be sure you're not getting unnecessary data
type conversions. Etc. (SQL performance is a large issue, as you say, beyond
the scope of this forum.)
----------

Yup.  But if I'm going to be able to answer the question of how to use Java/400,
I'm going to need to decide the question of database access.

Let's look at some of the options:

1. Java front end doing direct SQL calls
2. Java front end doing direct native I/O calls
3. Java front end talking via RMI to a Java server class using JDBC
4. Java front end talking via RMI to a Java server class using native I/O
5. Java front end talking via middleware to a Java server program using JDBC
6. Java front end talking via middleware to a Java server program using native
I/O
7. Java front end talking via middleware to an HLL program using embedded SQL
8. Java front end talking via middleware to an HLL program using native I/O

There are other options, of course, but they tend to veer away from the
client/server architecture.  Another thread can discuss why I believe so
strongly that client/server is required for true distributed applications, while
servlet technology is better suited for data collection applications (like order
entry).

Options 1 and 2 are out of the question for industrial strength applications
because of the problems with distribution of business rules.  Options 3 and 4
would be wonderful if the JVM was truly integrated into OS/400, but it isn't
yet.

That means we need to determine which of the other four options is the best.
The answer may be "it depends on the application", but that simply means we need
to spend a little more time defining the application.

Whew!  All that said, I think it's time to start building a test bed.  I've
already done a little of the groundwork in the May issue of Midrange Computing,
where I take a monolithic RPG maintenance program, break it into client and
server on the AS/400 then re-engineer the client on the workstation in Java.

Anybody who has ideas on how to proceed, please feel free to jump on in.  In the
meantime, I think I'll start by developing the Item class, with a factory method
that instantiates either a native I/O or SQL database subclass.

===================
Joe "Zappie" Pluta
www.zappie.net/java
"Where the AS/400 speaks Java with an RPG accent"
===================


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---