Yet another session problem...

I have a registration process that the user must go through at www.somedomain.com. All the variables entered are stored as session variables. On the last page of the process, when the user clicks Finish, the session vars are stored into the db.

The problem is sometimes it can take up to 30 minutes to register and the session vars are set to null because it times out.

I cannot set the timeout higher.

Any one have any ideas?

Would it be possible to create some "Keep alive" code and put it in the session end event so that when the session ends it automatically gets restored?

If anyone has tried this let me know

Thanks,
Pete


Post Edited (blabberblog) : 11/29/2004 4:08:01 PM GMT

 

well, four possibilities occur to me. they are:

<ul>[*]Store in ViewState[*]Store in Application [*]Store in Database[*]Store in Cache.[/list]

(Storing in Cache is really just a variation on storing in application) Application or cache isn't reliable. IIS 6.0 is pretty much allowed to restart the application whenever it wants. (There are actually a lot more rules than that, but you shouldn't rely on it for this type of data.) Also, you'd have to figure out a way to make it unique to the user who is registering and then key back into it, so we shall just chuck those two.

Next we have viewstate. Viewstate is client-side so it will live for as long as your web page. If it's "Wizard-like" functionality, you'd have to be able to carry the values form one page to another. So the process might go like:

Page 1: Get some data and store in session.
Page 2: Immediately get the data out of the session and store in viewstate. Get more data from page 2 and store that in session.
Page 3: Get the data from session and again store in viewstate.

Because the data is only needed in the session variable for the time it takes to go from page 1 to page 2, if the session dies while the user is filling out page 2, it doesn't matter because the data from page 1 is in page 2's viewstate.

The database alternative would have to work similarly. The (potential) user would fill out some stuff on form 1. At that point a record would be added to the database with a unique ID for that session. That would have to be stored client-side (Viewstate) so that the process could get the data back. The only reason I can see to store in the database is if you have very large items in your data, thus avoiding a large viewstate which could slow down response time.

Good luck!

 

Great.

I think the db solution is the best. I could store the items in the db from one page to the next along with a unique identifier.

Also pass the unique ID as a querystring from one page to the next so I could match it with the proper records in the db in case the session dies.

Thanks,