in reply to Re^2: Concurrent requests on the same CGI::Session
in thread Concurrent requests on the same CGI::Session

Sure... no problem.

The problem is twofold:   (a) that Session handlers normally replace the entire set of variables; and (b) that there is no “change counter.”   (Usually, database transactions are used, but that is not sufficient.)

Therefore, when two or more simultaneous requests start, both of them get the same set of initial-data, and the last one to complete overwrites the entire set of changes previously posted by all of the requests preceding it (in completion-time).   Precisely as the OP observed.

A more-sophisticated approach is needed, such as... partitioning the data, providing change-counters that are incremented with each update (of a given partition) and so on.   I am very interested to find session-support modules that can do these things automagically.   (Although such a thing can be written... “laziness is a virtue among programmers, you know.”)

Replies are listed 'Best First'.
Re^4: Concurrent requests on the same CGI::Session
by Anonymous Monk on Jan 17, 2011 at 16:24 UTC
    A more-sophisticated approach is needed, such as... partitioning the data, providing change-counters that are incremented with each update (of a given partition) and so on.

    Nowhere near detailed enough, though it does remind me of CHI -- either way, the app developer will always have to write his own state logic (think of TCP session and out of order packets, etc)

      A practical improvement need not be over-complicated; nor does it need to be overly general.   Database transactions, and for that matter the TCP/IP protocol itself, are more than sufficient to deal with “out-of-order packets.”   What we need here is a pragmatic improvement upon the sort of situation that the OP has described ... a session-store that is more cognizant of the practical needs of AJAX transactions ... and, a wheel that has no need of being re-invented.   That Is All.

      “We can rebuild him.   We have the technology ...”

        Thanks, that is much clearer :|