Storing IDs between pages for up to a day?

I need to store IDs (Contact IDs, Claim IDs, etc.)开发者_运维问答 between multiple .aspx pages.

At the moment I am storing the ID in the Session and have set the Session timeout to 300 minutes. However, I am still getting errors because users are attempting to perform operations after the Session has expired.

I think users are leaving their web broswers open, locking their computers, going home for the evening, coming in the next morning and attempting to pick up where they left off.

I don't want to use the Querystring. Cookies are more for User IDs than Contact IDs and Claim IDs. Viewstate is only maintained per page. Persisting Session to a database seems unnecessarily complicated. I don't want to extend the Session timeout too much.

I'd ideally like them to be able to pick up where they left off in the morning.

What are the best practices for dealing with storing IDs between pages? How can I do this without them receiving a message saying their session has expired? Am I overlooking something obvious?!

---

I would put all this information into a database. This is classic use of a database, a means to store information needed for the application.

Cookies are bad because you have to assume they will be at the same PC from session to session. You have seem the problem with sessions.

If you do not want to use a database then you can use a file on the server. And read from that file.

---

You might actually find it much easier than complicated to create a sort of "landing pad" database where a user's item history is stored, or MRU list. I wouldn't tie it to their immediate session or cookie though. Let the session maintain the user state, let the database handle where they were when they went home or took that 7 hour lunch break.

---

As @David said this is a classic use of databases.

If you are in need of doing this without using databases, you can fall back on some of the "tricks" (read hacks) that are used in non-dynamic languages:

1. Create a hidden field which exists on every page, name the field appropriately for the data you are storing.
2. When you render the page create an XML fragment containing your ids and other data, encrypt it for display purposes (using base64 etc), place the value into the hidden field you created.
3. When the page is posted back, reverse #2 and recover your data, then apply the page changes.
4. Rinse and repeat. :)

Really this is not a very scalable solution, as the XML and base64 encoding will add 50% or more to your data size, and if there is significant data (100's of KB) this process can get out of control.

The last time I was asked to use this solution it was for moving a list of well defined data around with an application that did not always have access to the DB. It worked ok for the purposes, but was definitely not ideal.

---

You could go ahead and store the IDs in viewstate on the page, then on each page that requires that ID have a settable property for that page. Before redirecting to the page instantiate it and set the ID property.

You're correct, storing this type of data in session isn't really what it's meant for. Viewstate is a better mechanism for this.