Does Session State read/write everything when you access with DynamoDB

Question

I have a C# .NET app that has a Session State that is backed by DynamoDB. However I'm noticing higher throughput that I would expect. However I notice in the actual table that everything is stored as SessionItems in one long string.

But let's say I'm storing multiple things in the session

Http.Context.Session["Object1"] = obj1;
Http.Context.Session["Object2"] = obj2;

Where obj1 and obj2 are instances of two different classes.

Now when I go to read or write one of these, for example::

var obj1 = Http.Context.Session["Object1"];

Is it reading everything that is stored in SessionItems on the DynamoDB table? That's one explanation that would explain higher throughput on the table but seems very unecessary.

Answer 1

Ideally, ASP.NET performs a single read and single write on a serialized collection of the objects stored in the user's session once on each request (e.g. page/controller). If you access multiple items from that collection on a request, it uses the local copy and will not have to access the underlying datastore.

However, what I think you are noticing is ASP.NET's pessimistic locking model. When it attempts to perform the single read to retrieve the user's session data, if that user's session data has a lock set on it already, it will continually retry to retrieve it (every 500 milliseconds).

The specifics of your ASP.NET HTTP lifecycle depend on framework version, etc, but the general concept is something like this:

1. Set exclusive lock on row containing session's data in datastore (If exclusive lock cannot be obtained, wait until it can)
2. Read/deserialize collection from datastore row for this session
3. Execute your page/controller
4. Serialize/write collection back to datastore
5. Remove exclusive lock

If you have multiple HTTP requests accessing a user's session (e.g. Ajax on a page) you will notice there is no concurrency because of exclusive locks - they execute serially if Session is enabled for each one. (even if they do not explicitly access Session).

One way to avoid this is to be intentional about where you write to Session, and on all other pages/controllers specify SessionStateBehavior.ReadOnly. When you do so, ASP.NET will not set an exclusive lock (will use GetItem instead of GetItemEx). See ASP.NET Session State Overview.

Page:

<% @Page EnableSessionState="ReadOnly" %>

Controller:

[SessionState(SessionStateBehavior.ReadOnly)]

Reference:

• Microsoft's ASP.NET DistributedSession.cs - example showing a Microsoft session provider.
• AWS's DynamoDBSessionStateStore.cs - source to AWS's session provider.
• ASP.NET Application Life Cycle Overview - older but demonstrates concept of request flow.
• Implementing a Session-State Store Provider - more on creating a session provider.

Hope this helps!

Regards,

Ross