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

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)

  • Comment on Re^4: Concurrent requests on the same CGI::Session

Replies are listed 'Best First'.
Re^5: Concurrent requests on the same CGI::Session
by locked_user sundialsvc4 (Abbot) on Jan 17, 2011 at 19:01 UTC

    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 :|