Thanks. 'Last save wins' would be fine as long as we could guarantee that the last save was actually the last request the user made.

The fundamental problem we're having is that intermittently, under relatively heavy load, sometimes the app just does not get the session data written on the previous request. I came across a situation recently where opening a page in a javascript window set up a kind of race condition with session data ... the request still being processed in the parent window seemed to prevent the request in the child from writing to the session. So we hypothesised that this might be what is happening (especially as Apache::SessionManager doesn't untie the session until the very end of the request, after content has been sent back to the client) and investigated the locking process to see if it was possible, because we thought locking should prevent that.

The most frustrating aspect to this session problem is that it affects the real users of the system much more than it does us the developers. We've only encountered the error once in testing, whereas they're getting it quite frequently. We're geographically very distant from the server whereas the users are quite close, so this sort of led me down the path of speculation that it's like a race condition between requests (because theirs would get back to the server much faster than ours). We've disabled javascript and redirects that send further content and this has improved things, but not fixed them. If we can't solve it, maybe we do need to look at storing the session data some other way.