Re: IceBreak as an alternative to Apache?

In an rpg environment we have tried user indexes to store session data - we have also used user spaces. However, these days nothing seems to beat a good old fashioned physical file. A lot made of the overhead involved in maintaining state this way, but I believe it to be slightly misleading. The IBMi does this extremely quickly, and the amount of session data stored even in our most complex apps is small enough for it to be a non-issue.

I would like to try a stateful web app, but with so much code already written for a stateless environment it is difficult to justify the experiment.

On 31 Dec 2010, at 20:19, "Maurice O'Prey" <Maurice.Oprey@xxxxxxxxx> wrote:

OK Joe

Thanks for the clear introduction to 'State'. I understand that the 'session
id' is stored in a cookie or in a cookieless environment it is included in
the request or query string.

My question really is how do people using the i store the information that
is related to that session ID, e.g. in server memory (by Session ID),
written to disk (out of state storage) or is there an application level of
State, again stored in server memory?.

Can 'State Objects' be stored in the Server Cache and retrieved from there,
if so what types of objects can be stored and how are they retrieved and
re-instantiated?. Is there an equivalent of ViewState as used in .NET? Of
course there is a painful overhead but that can't really be avoided.

I guess the answer differs depending on whether your using, RPG(le), PHP,
EGL or other.

- Maurice



Typically there's a session ID somewhere in the transaction that's used
to retrieve all the appropriate state information. The state
information is persisted (the fancy name for "written to disk") on every
request and then retrieved on the next request. As you might guess,
this adds significant overhead. It's particularly painful when you need
to re-open and reposition database cursors.

Joe

Just as a question

How do you all manage state in the HTTP stateless environment? What is
state?

Happy new year

Maurice O'Prey

--
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.

--
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.

NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.



--------------------------------------------------------------------------------


CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT

Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.