I've got to disagree. On a properly sized machine (won't be running 2.1B
rows on a 515) with the right indices you should get results back in
several ms.
I would agree with you there. My experience is on a 520, so processing
that amount of data seems like a mountain.
That's against "proper" web design. The web is stateless, to try to pair
a specific client to a specific server-job is against the "rules."
There's no reason you can't share that connection, you just have to be
smarter about how you page the results.
I'm not trying to suggest pairing a specific job to a specific
connection. But his server side code shouldn't be written in such a way
that a new request will not cause bad results to be returned. THAT is bad
design. His code should be designed that no matter what makes the call,
the results will be correct based on the parameters passed. This is what
he is trying to accomplish, as of now his code isn't written in such a
manner. I'm guessing he's using Setll and Reade as opposed to using
embedded SQL?
Thanks
Bryce Martin
Programmer/Analyst I
Ext. 4777
"Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
01/09/2009 10:27 AM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
To
"RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
cc
Subject
RE: RRN and Database Files
Any DB file with that many records is going to take forever to
processes.
I've got to disagree. On a properly sized machine (won't be running 2.1B
rows on a 515) with the right indices you should get results back in
several ms.
I think that instead of modifying your RPG code you
should take a look at reworking your java code so that you can have
multiple users.
That's against "proper" web design. The web is stateless, to try to pair
a specific client to a specific server-job is against the "rules."
There's no reason you can't share that connection, you just have to be
smarter about how you page the results.
With proper SQL and cooperation from the app you can get paging
performance to be independent of the page# you're on. This was discussed
last year sometime on the list (don't recall whether it was this one of
Web, or Midrange)
Having said that, I don't see why the change was made initially away
from returning all the rows. I'm assuming (dangerous, I know) that we're
not talking about 10s of 1000s of rows here, but perhaps 300 per client?
Maybe 1000. Should have been ok on one request, but I don't know the
app.
-Walden
As an Amazon Associate we earn from qualifying purchases.