Re: Thinking out loud about a new RPG web framework

Gents;

I have been watching this thread, and all ideas (so far) are part of
IceBreak.

So my question: Would it be interesting for you guys if we made IceBreak
open-source?



Best regards


Niels Liisberg
IceBreak Chief SW Architect

System & Metode Technologies
Håndværkersvinget 8, DK-2970 Hørsholm
Phone: +45 70 20 36 10
Fax: +45 70 20 30 11
Direct: +45 45 177 055
Mobile: +45 31 158 861
E-mail: nli@xxxxxxxxxxxxxxxxx
Web: www.system-method.com and www.Icebreak.org



-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Thorbjørn Ravn Andersen
Sent: 9. juni 2008 21:44
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Thinking out loud about a new RPG web framework

Joe Pluta skrev den 09-06-2008 19:30:

Thorbjørn Ravn Andersen wrote:

This turned out to be both an interesting exercise and a learning
experience regarding different . It is not a problem to store a
scrollable resultset as a session attribute in JSP and navigate back and
forth with a PostgreSQL database on OpenSolaris so that was working

nicely.

Hold on though - this means you need a stateful HTTP session, right?
That is, you keep the database connection from one request to the next.
If you have that and 1000 users, and you all use a connection pool with
only 100 entries, then the pool will run out of connections. It's
basically a stateful design.

I did not advocate against stateful designs. I advocated against having
statefulness more than one place, and you said that I could not create
an application which could page the result of an arbitrary SQL command
without recreating the query every time. Hence this is what I am
looking at creating a proof-of-concept for.

Connection pools should grow and shrink as needed.

It then turned out that the PostgreSQL JDBC driver loads the complete
resultset in memory when needing to be able to page back and forth,
which was the whole idea to avoid so that was an unpleasant surprise
having 11 million rows in my testset. So now I've learned that not all
JDBC-drivers are created equal :)

I expected this. If the result set is truly disconnected, then you
would have to either hold all the data in memory, or else you have to
create a new index each time.

Or the database would be smart enough to keep the query active and allow
the resultset to navigate. This is currently what I expect the i to
be able to.

--
Thorbjørn