I actually think that this is a very interesting question and am surprised not to see more comments already in this thread ...

Based on the fairly simple overview of the process in place currently, I think the solution lies within the means by which you store your session and input data. From the overview given, I am guessing you are making use of client-side storage of the data entered within the 'session', hence the problem when the input train is interrupted. This is where your biggest mistake lies ... Client-side cookies should not be used for any 'real' sessional data storage - Instead, the client-side cookie should only store a unique, and preferably, non-predictive and pseudo-random, pointer to the storage of this data on the server.

How can this work with the given scenario? Well, the answer to this question will depend very much upon the specifics of client cookie management and server-side data storage with your script. However, imagine the following as an order of operation for your application ...

This method could be streamlined through the use of a server side session management and data storage solution such as Apache::Session - Indeed, if you really wanted to, you could actually take out the final step of this process by expanding your existing database tables to include sessional identification such that data entered during the session could be submitted to and updated within the database as entered. The expansion of data storage in this manner, paired with a second table matching up client environment details, collected at the time of session initiation, with the sessional identification would allow you to track user-entered data quite precisely.

The approach of pooling data from sessions into half-hour blocks for submission, collectively referring to them as a sessional entered unit, really doesn't scale too well to a system where you might have dozens of people entering information at once. Furthermore, by collecting the data server-side in this manner forms the rudiments of a 'true' sessional system, similar to that described previously.

Good luck

 

perl -e 's&&rob@cowsnet.com.au&&&split/[@.]/&&s&.com.&_&&&print'


In reply to Re: A CGI chained-event theory question by rob_au
in thread A CGI chained-event theory question by JPaul

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.