How to avoid simple race conditions with Session?

Rails
1

Here is the situation:

  • the client makes a request
  • it is followed by AJAX polling

The server needs to keep track of some stuff during this process.

I have been using the Session and it “mostly” works until the user
decides to open another tab in her browser and she makes a new,
parallel request. In this case, the data from the two requests is
merged, which leads to bugs.

This got discussed quite a bit several years back, but I could not
find any recent “recommended” solution to handle this. Does it exist?

I read in this article (session - Rails - Store unique data for each open tab/window - Stack Overflow
rails-store-unique-data-for-each-open-tab-window) that an option could
be to prefix the URLs, but it seems quite complicated to me.

Thanks a lot!
PJ

2

On Thursday, January 3, 2013 11:26:25 AM UTC, PierreW wrote:

merged, which leads to bugs.

Actually it’s far more likely to be overwritten completely.

This got discussed quite a bit several years back, but I could not
find any recent “recommended” solution to handle this. Does it exist?

Personally i think this can’t be solved with the cookie store: any given
request handler can’t know what might have happened to the session in
another request. A long time ago i wrote a database backed session store
that tried to handle this gracefully (smart_session_store). As long as
the
different actions were using different keys in the session it worked
fine.
If you need more sophisticated merging behaviour I would suggest that
the
session isn’t the write data store for you

Fred

3

And also: in this instance I don’t need any data merging. I just need
to make sure each “request” (HTTP + following AJAX) is using its “own”
stuff. Each request from different windows / tabs is completely
independent.

4

On Thu, Jan 3, 2013 at 5:54 AM, PierreW [email protected] wrote:

And also: in this instance I don’t need any data merging. I just need
to make sure each “request” (HTTP + following AJAX) is using its “own”
stuff. Each request from different windows / tabs is completely
independent.

Why not have the Ajax generate a token of it’s own and send it along?
That way the browser handles it’s own uniqueness and tabs are
included. You then use that uniqueness to track the data in the
database (or redis or whatever suites your purposes) rather than using
the session ID. Of course you would also use the session + sesson id
to track which unique identifiers belong to a client but yeah. The
only downside is that then you also have to timeout if they don’t
respond after a certain period or you end up with a million
identifiers you don’t need.

5

On Thursday, 3 January 2013 06:26:25 UTC-5, PierreW wrote:

Here is the situation:

  • the client makes a request
  • it is followed by AJAX polling

Based on this short description, have you considered using something
like
WebSockets? The request-followed-by-polling sounds like an attempt to
create a persistent connection the server can push data to, but using a
technology intended to do just that may be less hassle…

–Matt J.

6

I agree, just generate a unique token for each initial request and then
segment your session data by that key.

7

Thanks a lot Fred.

I should have added: I am not using the Cookie Store, but
ActionDispatch::Session::CacheStore (Dalli in my case). But I am not
sure how it helps. Is there a way to tell which browser window / tab
is making the request (via a unique ID)?

Thanks!
PJ

On Jan 3, 11:44am, Frederick C. [email protected]