Q:

Session handling on web apps

I've been reading about sessions, both client and server side as well as few attacks possible on them. I'd like to know what are the practical solutions to the following problems related to sessions

Race condition between two request trying to change the session variables
When session ids are regenerated, what happens to the slow requests that reach the server with older session id 

A:

For your first question, see here for how ASP.NET handles this - "Synchronizing Access to the Session State":

What if other pages attempt to concurrently access the session state?
  In that case, the current request might end up working on inconsistent
  data, or data that isn't up to date. Just to avoid this, the session
  state module implements a reader/writer locking mechanism and queues
  the access to state values. A page that has session-state write access
  will hold a writer lock on the session until the request terminates.

For your second question this would be down to your code regenerating the session identifier at a suitable point. For example, to avoid session fixation it is good to regenerate the session identifier upon login. At this point there should not be other, slow requests being made to the server, so therefore this is an optimal time to issue a new identifier.
In other situations it may be appropriate for your application to recognise expired session identifiers for a short time, and associate them to the new identifier until all connections have been closed.

