Variables: Session vs. Client vs. Cookie

[Guest]

I have a couple of apps that have use a multi-step input form to input some complicated data. As the user goes through the steps the data is saved in a SESSION. variable (actually a struct in one case and an arrary of structs in the other) before being inserted into the DB at the end. It all works fine except that sometimes people get called away from their computer in mid task (or are otherwise distracted) and when they come back, their session has expired and their partially entered data is lost.

The actual data they are entering is not sensitive so I am considering saving the data in a cookie at each step using WDDX to store the complex variable. I'll test to see if the SESSION variable is missing and if it is, recreate it using the data in the cookie. If the full steps are competed successfully, both the SESSION.variable and the Cookie are destroyed.

1) Is there a better way to do this?

2) If I was starting again, is there preferred way to store the data temporarily until it is inserted into the DB?

Magnus

[mack_]

You could use Session variables but also a timer that periodically

pings the server to keep the session alive (for example you can use

jQuery to ping the server asynchronously). The timer should be used

only on the pages where the actual data is entered otherwise your

sessions will not expire as long as the user has a page open.

Depending on the size of your data you can also store the info in a

cookie (maximum practical length for cookies seem to be at around 4K

so if your data is larger then that it will not work).

Mack

[TLC-IT]

A cookie is not an appropriate mechanism for this purpose.

Options include:

1. In your application, provide a way for people who know that they're going to be "distracted" to save their work and then come back to it.
2. Add a small JavaScript loop that, on a timer, periodically "pings" the server just to keep the session data alive.
3. Add an auto-reply filter on your e-mail system so that, whenever users complain, it auto-replies to tell them that it's their fault not yours.


4. Increase the session time-out interval on the server.

This is one of those things that, quite frankly, can demand far more time and re-work than it will ever deserve.  There comes a time when you simply have to tell people, "that's just the way that this application works.  Come to a good stopping place before you take off doing something else."  Given that the application works well just the way that it is, this is a compelling rationale not to rip the thing apart just for a dubious "fee-chur."

[ilssac]

TLC-IT wrote:

1. Increase the session time-out interval on the server.

I give up, that should be 4. but this lovely forum has desiced that it will be a 1 since I cut some text and I can't convince it otherwise.

Anyway I wanted to point out that if this is a vialbe option one can set a page specific session time out with the <cfsettting...> tag.  So that one does not need to modify the value for the entire ColdFusion server just for one part of a single application that may need a bit longer.

[mack_]

Ian,

I don't think you can modify the session duration for a single page

using cfsetting. As far as I know the session timeout is decided when

the cfapplication tag is encountered and it's the same for all

sessions variables within an application.

Mack

[ilssac]

Sorry, you are right I was confusing requestTimeout with SessionTimeout.

You can do it by providing a <cfapplication...> tag for this section with a longer timeout then other sections of the site.

[TLC-IT]

Reviewing this situation, I advise simply "increase the timeout."  Also, educate the users.  Advise them, somewhere on the screen, that a single editing session will time-out after 30 minutes (or whatever) of inactivity.  I've also seen sites that use JavaScript to display a reminder, make noise etc when they detect inactivity on the client side.

It isn't unreasonable for an edit-session to time out.  You're simply wanting to make sure that it does not inconvenience users who have become momentarily distracted by the presence of other alligators.   A note, and maybe a little JavaScript wake-up call (Zzzzzzzzz... huh? oh yeah...) might be just what the doctor ordered.  Making massive and disruptive rewrites to "an intricate application that works" is not.

[Zero_Sequence1]

Simply save the cfid, cftoken of the visitor in a cookie,

when he starts the multistep program create a record from which one column would be "completed"

so until the visitor has completed the progress it will stay in the "incomplete" status..

if he returns after the session has ended he will be able to finish his job...

[TLC-IT]

Yes, unquestionably, if the ability to save the incomplete session is sufficiently important, you can serialize the data to some database-table of your own devising, much as CF itself will do.  You can code your application so that it, as they say, "freezes" and "thaws" the necessary data each time to your own data-store.  You can even put that business into a nice CFC-routine.  It's really just a question of how disruptive that would be, how much work that would be, what the "cost/benefit analysis" would be.  It might, of course, be "a huge win."

In essence, you would remember the user-identity, a timestamp, maybe even a version number, the complete/incomplete status, the permanent identity of the place where the finished record was ultimately filed when it was finally declared complete, and a BLOB-field containing the serialized data itself.  You could, if you so chose, provide the ability to keep an arbitrary number of works-in-progress.  You could write JavaScript to do "auto-save."