Enable ASP.Net Core Session Locking?

Question

According to the ASP.Net Core docs, the behaviour of the session state has changed in that it is now non-locking:

Session state is non-locking. If two requests simultaneously attempt to modify the contents of a session, the last request overrides the first. Session is implemented as a coherent session, which means that all the contents are stored together. When two requests seek to modify different session values, the last request may override session changes made by the first.

My understanding is that this is different to the behaviour of the session in the .Net Framework, where the user's session was locked per request so that whenever you read from/wrote to it, you weren't overwriting another request's data or reading stale data, for that user.

My question(s):

1. Is there a way to re-enable this per-request locking of the user's session in .Net Core?

2. If not, is there a reliable way to use the session to prevent duplicate submission of data for a given user? To give a specific example, we have a payment process that involves the user returning from an externally hosted ThreeDSecure (3DS) iFrame (payment card security process). We are noticing that sometimes (somehow) the user is submitting the form within the iFrame multiple times, which we have no control over. As a result this triggers multiple callbacks to our application. In our previous .Net Framework app, we used the session to indicate if a payment was in progress. If this flag was set in the session and you hit the 3DS callback again, the app would stop you proceeding. However, now it seems that because the session isn't locked, when these near simultaneous, duplicate callbacks occur, thread 'A' sets 'payment in progress = true' but thread 'B' doesn't see that in time, it's snapshot of the session is still seeing 'payment in progress = false' and the callback logic is processed twice.

What are some good approaches to handling simultaneous requests accessing the same session, now that the way the session works has changed?

Answer 1

The problem that you have faced with is called Race Condition (stackoverflow, wiki). To cut-through, you'd like to get exclusive access to the session state, you can achieve that in several ways and they highly depend on your architecture.

In-process synchronization

If you have a single machine with a single process handling all requests (for example you use a self-hosted server, Kestrel), you may use lock. Just do it correctly and not how @TMG suggested.

Here is an implementation reference:

1. Use single global object to lock all threads:

  private static object s_locker = new object();

  public bool Process(string transaction) {
      lock (s_locker) {
        if(!HttpContext.Session.TryGetValue("TransactionId", out _)) {
           ... handle transaction
        }
      }
  }

Pros: a simple solution Cons: all requests from all users will wait on this lock

2. use per-session lock object. Idea is similar, but instead of a single object you just use a dictionary:

    internal class LockTracker : IDisposable
    {
        private static Dictionary<string, LockTracker> _locks = new Dictionary<string, LockTracker>();
        private int _activeUses = 0;
        private readonly string _id;

        private LockTracker(string id) => _id = id;

        public static LockTracker Get(string id)
        {
            lock(_locks)
            {
                if(!_locks.ContainsKey(id))
                    _locks.Add(id, new LockTracker(id));
                var res = _locks[id];
                res._activeUses += 1;
                return res;
            }
        }

        void IDisposable.Dispose()
        {
            lock(_locks)
            {
                _activeUses--;
                if(_activeUses == 0)
                    _locks.Remove(_id);
            }
        }
    }


public bool Process(string transaction)
{
    var session = HttpContext.Session;
    var locker = LockTracker.Get(session.Id);
    using(locker) // remove object after execution if no other sessions use it
    lock (locker) // synchronize threads on session specific object
    {
        // check if current session has already transaction in progress
        var transactionInProgress = session.TryGetValue("TransactionId", out _);
        if (!transactionInProgress)
        {
            // if there is no transaction, set and handle it
            HttpContext.Session.Set("TransactionId", System.Text.Encoding.UTF8.GetBytes(transaction));
            HttpContext.Session.Set("StartTransaction", BitConverter.GetBytes(DateTimeOffset.UtcNow.ToUnixTimeSeconds()));
            // handle transaction here
        }
        // return whatever you need, here is just a boolean.
        return transactionInProgress;
    }
}

Pros: manages concurrency on the session level Cons: more complex solution

Remember that lock-based option will work only when the same process on the webserver handling all user's requests - lock is intra-process synchronization mechanism! Depending on what you use as a persistent layer for sessions (like NCache or Redis), this option might be the most performant though.

Cross-process synchronization

If there are several processes on the machine (for example you have IIS and apppool is configured to run multiple worker processes), then you need to use kernel-level synchronization primitive, like Mutex.

Cross-machine synchronization

If you have a load balancer (LB) in front of your webfarm so that any of N machines can handle user's request, then getting exclusive access is not so trivial.

One option here is to simplify the problem by enabling the 'sticky session' option in your LB so that all requests from the same user (session) will be routed to the same machine. In this case, you are fine to use any cross-process or in-process synchronization option (depends on what you have running there).

Another option is to externalize synchronization, for example, move it to the transactional DB, something similar to what @HoomanBahreini suggested. Beware that you need to be very cautious on handling failure scenarios: you may mark your session as in progress and then your webserver which handled it crashed leaving it locked in DB.

Important

In all of these options you must ensure that you obtain lock before reading the state and hold it until you update the state.

Please clarify what option is the closest to your case and I can provide more technical details.