RE: What is Performance -- JAVA400-L

> From: Dieter Bender
> 
> Joe, this cant be the rule of the game. In your originating posting
you
> claimed performance benefits of rpg business logic components of 10 to
100
> times. It can't be my work to prove that this numbers are by far too
high.

If you can't prove your statements, don't make them.  If you don't like
my statements, disprove them.  Until then, my arguments are as valid as
yours.  In this game, Dieter, only numbers talk.


> To make it simple let us discuss this on your example for the programm
> call (the counter).

Okay.  What I'm going to do is create an architecture which disproves
your contention that we cannot use pooling AND talk to a stateful RPG
session.  At that point, will you then finally agree that perhaps you
don't know as much about scalability as you contend?  And that perhaps
some of us know how to write high-volume Java/RPG applications?


> If you would use this rpg counter to put the number of
> transactions on every JSP increasing it by 1 for every JSP shown for
the
> user
> in his session, you would have to put the AS400 Connection for the
> programm
> call in the session object of your Web Application, otherwise you
would
> loose
> the state of the rpg counter programm from one call to the other.

Wrong.  I save the name of a data queue in my session object and use a
pooled connection to talk to the data queue.  I only need the pooled
connection for as long as it takes to communicate with the data queue,
which is very brief.  The data queue serves as a conduit to a stateful
job that can do anything I need.  Synchronization is not an issue, state
is not an issue.

That's just ONE way to provide scalability and it works even for load
balancing, since my data queues can be used to talk to remote machines.
In fact, this is a really nice way to front one large iSeries for
business logic processing with a number of small, inexpensive we serving
boxes.

And I can think of other ways, Dieter.  Your analysis of the system is
simply incomplete.


> With such a design you would not survive a design review by an
independant
> third party in case of trouble with your custumor on the scalability
of
> your
> application. (I took part on such reviews as consultant for a
> softwarehouse
> and we came in problems, because they stored the JDBC Connection in
the
> session).

I couldn't care less about third party audits, because frankly most
auditors don't have a clue about the iSeries, as we've seen over and
over again.  The iSeries is BUILT to scale; if people used the iSeries
(correctly) rather than Wintel platforms, we wouldn't need to have
independent third party auditors.  But even so, by simply storing a data
queue name in my session, I'm completely serializable and thus load
balanceable.

Anyway, hopefully I've shown you one simple example of thinking outside
the box you've placed on the iSeries, and on Java/RPG communication.  As
I said, the iSeries is built to scale (hey IBM, how's THAT for a
slogan?).

Joe