force db update at log out

gwalsh

I am creating a service involving on-line administration of a series of psych tests. The design goal is to present the client with a 'look and feel' akin to the usual paper-and-pencil environment. This means the client can browse all the items on a test, answer them in any order (s)he wishes and change one's answers, just as is the case with all standardized testing. Further, the client is under no requirement that a test be completed at a 'sitting', but (s)he cannot select another test section without first finishing the current one. Once a test section is completed, it cannot be accessed - ie, that test booklet is 'handed in'.

For these reasons among others, we opted for server side handling rather than the usual client side handling - one response at a time.

The environment involves PHP5, CSS with XHTML 1.1 and PostgreSQL8.3.

Once authenticated, a session is started each time a new test is selected or an existing one called up for completion.

All of this works very smoothly but with one probable glitch.

We have provided a session length of 7200 (2 hours) which is at least twice the time any one section would take to complete.

What is going to happen when a client leaves the site and does not return before the session expires?

Any responses provided on the current test are going to be lost. At present, responses are transferred to the database only when the test is completed or the client requests that the work be saved at that point in time.

Ideally, what I need is a way to insure against this situation happening, but I do not understand how or even if that could be accomplished.

Suggestions, anyone?

ucffool

Technically I can't explain it, but you basically need a constant connection on the page that automatically saves their entries so far every, say, 60 seconds. This is like the 'auto-save' you find in gmail and numerous other services. I'm not an expert on the javascript to do this, just know it exists.

NogDog

My preference would be to save the responses in the DB from the get-go, rather than depending on client-side operations to determine when/if it gets saved.

gjwalsh

Thanks for the suggestions, NogDog and ucftool.

I have come to this point because of the earlier decision to process at the server with php rather than the client with javascript, which would only mean I'd have to confirm again with php anyway.

I understand the preference for updating the db with each response from the client but that seems very hard on resources, given the an average battery will involve a dozen separate tests which together involve just over 1,000 individual form responses.

Sessions work very well in beta testing, given that a session is refreshed with the start of each section, which is in itself determined by the client. As mentioned earlier, I've currently set the maximum session time constraint to 7200 - twice the time usually required for the 'worst possible case'.

Since php is popping these responses into a string and then to the db, I guess the best compromise is to refresh the db either after so many responses have been selected or so many minutes have passed. Messy, but I understand the reason for it.

Your input is much appreciated.

George

gjwalsh

Missed a BIG point here.

Wasn't in a real panic about sessions expiring until I noticed that on a beta test from last night, sessions are NOT refreshed in terms of expiration time. When the accumulative 2 hours runs out, its 'over'. While I consider the other matters discussed I am going to extend a session to 7 days and gain some breathing room for further testing .... thought I'd best clarify this for others who might be trying to follow along with this thread..

George

NogDog

You seem to be jumping to a conclusion that a database solution will be significantly slower than a sessions solution. However, with a reasonably designed database with proper indexing, this may not be a valid assumption, depending on how you define "significantly slower". For instance, if it takes 10 milliseconds more to use a database solution versus a file-based sessions solution, a human wouldn't even notice the difference, and you wouldn't likely need to worry about it unless you have hundreds of concurrent users with several hitting the server every second.

So unless you already have empirical evidence that suggests the database solution would be "significantly" slower, I would take the advice of the XP community and develop the simplest solution that works. Then if testing indicates it does not perform adequately, start looking for ways to refactor it in order to achieve acceptable performance levels; but don't spend lots of time now for something that may not, in fact, be a real issue.

gwalsh

Actually, NogDog, I am more concerned about maintenance of php scripts than in split second timing at the postgresql end. I ran responses into positions within a string using both php and good old 'C' on 1500 samples and was more than happy with the results. Then I set the strings into db columns and that worked smoothly and efficiently too. Rewriting a test's response strings over and over seems counter-intuitive, but no more so than a db's array elements, given how they are managed.

ucffool

gjwalsh wrote:
Thanks for the suggestions, NogDog and ucftool.

Wow, if that isn't the meanest typo ever....

gjwalsh

ucffool wrote:
Wow, if that isn't the meanest typo ever....

Well, it was paved with good intent. Couldn't discern between tool and fool so I took the more pragmatic option .....