By having a connection for every user session you may run into a
scalability problem since you require the user to log out to regain the
resources allocated to that connection.

I would be curious to know how many users you could support on say an entry
level 520 with 4GB of RAM, because the same issue you are proposing is
present in applications that are written in 100% JSF apps too where the
controllers are set to type "session", correct?

Here's a question: Let's say we had an entry level 520 with 10,000 users on
it using 5250 screens. I am guessing OS/400 appropriately pages RPG program
instances out to disk when it needs to free up memory for more active jobs,
correct? So in theory you could support 10,000 users though the swapping of
memory for disk (and vice versa) would make for some slow responses, but
would still work, and you could then just buy more processing power to
address the situation.

I am not trying to promote poor application infrastructure design, but more
trying to find a balance of leveraging RPG/OS400/DB2 features to build apps
faster while still having it be scalable.

Aaron Bartell
http://mowyourlawn.com

On Fri, Jun 6, 2008 at 8:08 AM, Thorbjørn Ravn Andersen <
thunderaxiom@xxxxxxxxx> wrote:

Joe Pluta skrev den 06-06-2008 14:37:


Which is why I say create a single connection at the beginning of the
session and use it throughout. You need connection pooling when you
have a stateless architecture that requires reconnection for every
request.

By having a connection for every user session you may run into a
scalability problem since you require the user to log out to regain the
resources allocated to that connection.

By properly using a pool for connections you can have long session
timeouts and short idle times for connection timeouts allowing you to
serve more users on the same hardware.

This naturally requires that the backend calls are stateless - all
needed information is passed from the session object - which you must do
anyway since this is for web users.

--
Thorbjørn

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.