Sessions. Cookies. The request. This problem is boilerplate for all
interactive web technologies.
Every web application framework for every platform and language environment
that I'm aware of has support for sessions and cookies. However, the IBM i
native virtual machine environment is somewhat unique in that you can also
maintain session data by launching unique JOBs for every client session.
The "Job" maintains all session data, for the duration of the session.
When IBM i Jobs maintain sessions, that saves you the overhead of parsing,
saving, and restoring session data for each and every request. It also
saves the transport overhead pertaining to sessions and cookies that are
the common lot of every other platform and language environment.
With a Job-based sessions, you can open as many files and SQL cursors as
you want, with any number of indexes and SQL filters (where clauses, etc.).
You never have to re-position record pointers or refresh SQL result sets,
which is common with other platforms.
Job-based sessions free developers to focus on application functionality
without any thought about what data needs to be saved and restored between
client-requests. You can call (activate) as many programs as you want and
they all share the same session data.
We typically launch a unique IBM i Job every time a user clicks on a menu
item in our web portal. A new tab appears, which displays the application's
entry-point screen. The portal sends an "end" request to the Job when the
"Exit" link is clicked, or after a period of inactivity is reached, which
enables programs to close files, free resources, and finalize processing
before the Job and session are ended.
midrange.com
