Frank is definitely right. You will have to decide. You can store data
in a database too. If you have a situation where the data is
particularly session oriented, then storing in the session makes sense.
However, remember the odd things that can happen with things like
popups, frames, etc. I personally prefer to use an application level
multithreaded program that does this stuff, relying on my own algorithms
and not upon session management in the container.
Frank W. Zammetti wrote:
Session is probably the way to go. For things like this, i.e., data
that is transient on the whole but needs to persists across a number
of requests, session is probably the right choice.
Why WOULDN'T it be the right choice? If your storing a lot of data,
session can become a problem, especially if you might deploy to a
distributed environment. Second, if you expect a very large number of
requests, you may find server resources being chewed up more than
you'd like and performance might ultimately suffer. Also, if you need
the capability of saving the steps of the wizard for later, you'll
need a more permanent persistence mechanism. These are just some of
the concerns.
All that being said, from what you describe, I'm thinking session
without hesitation. Not much data, your entire process takes a couple
of steps then some final result (which may be more permanently
persisted, I don't know)... Session coding will be very easy, and
unless your going to have a huge load, there shouldn't be any
problem. Only you know all the details though, so you'll have to make
the real determination.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
