« logging.statisticsShoji Catalog Protocol version 2 »

A replacement for sessions


Permalink 03:36:05 pm, by fumanchu Email , 1233 words   English (US)
Categories: IT, Python

A replacement for sessions

I'm tired of sessions. They lock for too long, reducing concurrency, and in my current case, don't fail gracefully when a request takes longer than the session timeout.

Problem: Session locks

Session implementations typically lock very near the beginning of a request, and unlock near the end of a request. They tend to do this even if the current request handler does no writing to the session. Why so aggressive? Because the typical test case trotted out for sessions is that of a page hit counter: session.counter += 1. What if the user opens two tabs pointing at the same page at once? The count might be off by one!

But if you don't do any counting, what's the benefit of such aggressive, synchronous locking? What we could really use is a system that used atomic commits instead of large, pessimistic locks.

Problem: Session timeouts

Sessions are often used for sites with thousands, even millions, of users. When any one of those users walks away from their computer, the servers usually try to free up resources by expiring any such inactive sessions. But lots of my admin-y sites have a few dozen users, not thousands. I'm just not that concerned with expiration of session state. I'm a little bit concerned, still, with cookies, so I still want to expire auth tokens. But there's no need to aggressively expire user data. But I find my current apps are so aggressive at expiring data that we frequently get errors in production where request A locked the session, and while it was processing a large job, request B locked the session because A was taking too long. B finishes normally, but then A chokes because it had the session lock forcibly taken away from it. Not fun.

What we could really use is a system that allows tokens to expire, or be reused concurrently, without forcing user data to expire or other, concurrent processes to choke.

Problem: Session conflation

Sessions are used for more than one kind of data. In my current apps, it's used to store:

  1. Cookie tokens. In fact, the session id is the cookie name.
  2. Common user information, like user id, name, and permissions, and
  3. Workflow state, such as when a user builds up an action over multiple pages using multiple forms.

The problem is that each of these three kinds of data has a different lifecycle. The session id tends to get recreated often as sessions and cookies time out (taking all of the rest of the data with it). The user info tends to change very rarely, being nearly read-only, but is often read on every page request (for example, to display the user's name in a corner, or to apply the user's timezone to time output). Workflow data, in contrast, persists for a few seconds or minutes as the user completes a particular task, and is then discardable at the end of the process; it never needs concurrency isolation, because the user is working synchronously through a single task.

Sessions traditionally lump all of these together into a single bag of attributes, and place the entire bag under a single large lock. What we could really use is a solution that had finer-grained control over locking for each kind of data, even for each kind of info or workflow!

Solution: Slates

We can achieve all of the above by abandoning sessions. Let's face it: sessions were cool when they were invented but they're showing their age. And rather than try to patch them up and keep calling them "sessions", I'm inventing something new: "slates".

I'm implementing slates in MongoDB, but you don't have to in order to get the benefits of slates. All you need is some sort of storage that uses atomic commits, and that allows you to partition such that you have a moderate number of "collections" (one for each user, plus a special "_auth" collection), and a moderate number of "documents" (one for each use case) in each collection. Let's look at an example:

$ mongo
MongoDB shell version: 1.6.2
connecting to:
> use slates
switched to db slates
> show collections
> db.admin.find()
{ "_id" : "user", "userid" : 999, "readonly" : false,
  "timezone" : null, "panels" : [
    [1, "pollingpoint"],
    [2, "unsampled"],
    [4, "test_redirect"],
    [6, "test_redirect_manual"]
], "staff" : true }
{ "_id" : "new_id_set", "name" : "My set",
  "ids" : [ 84095, 3943, 39845, 112, 9458, ... ] }

As you can see, there is a collection for the username "admin". It contains 2 documents.

User info

The first returned document is what I called "user info" above: things most pages want to know about the logged-in user. They're read for almost every request but changed hardly ever, and when they're read, it's very near the beginning of the request. Here's the Python code I use to grab the whole document:

request.user = Slate(username).user

...which is API sugar for:

request.user = pool.slates[username].find_one('user') or {}

Most pages perform this quick read and never write it back.

Workflow data

The second document returned above is workflow data for a domain-specific process I called 'new_id_set': the user uploads a large number of id's in a CSV file and gives them a name. But if there are problems with a few of the id's, we want to ask the user whether to discard the conflicts or continue anyway. But we don't want to go making records in our Postgres database tables until the numbers are confirmed, and it's prohibitive to have the client upload the same file again after confirmation. So we need a temporary place to stick this data while the user is in the middle of the activity.

Slates to the rescue! Unlike sessions, which tend to dump all their data into a single big bag, when we use slates we store our data in multiple 'bags'. That means that our user can upload their ids, be prompted for confirmation, go elsewhere to investigate the conflicts further, and come back and confirm the ids. The time they spend investigating incurs no performance penalty, because those pages don't load and re-save the 'new_id_set' slate--only the pages directly concerned with that particular slate do. Once the user has confirmed the upload, the slate is deleted.

Auth tokens

Most of the use cases for slates fit nicely into "user slates"; that is, a collection that is identified by the user's username. But when you receive an auth token in a cookie, how do you match it to a username so you can look up the slate?

The answer is to create a special, global slate which I named "_auth" in my implementation. You can name it whatever you like. This collection contains a map from tokens to usernames:

> db._auth.find()
{ "_id" : "abcdef09345", "token" : "94ee8f572",
  "username" : "admin",
  "expires" : "Wed Sep 22 2010 13:39:51 GMT-0700 (PDT)"}

When a user visits a page, their token is searched for in the "_auth" collection, the username is retrieved, and that value is stored for the request. Typically, their "user info" slate is then retrieved. Finally, if they are visiting a page that participates in a slate-based workflow, that slate is retrieved (and saved if any changes are made).


Slates provide finer-grained locking than sessions in order to meet the varying needs of auth tokens, user info, and workflow data. They lock for much shorter durations, over smaller scopes, and take advantage of the native atomicity of the storage layer (MongoDB, in my case) allowing much more parallelism between requests.

1 comment

Comment from: packers and movers in Delhi [Visitor] · http://packersandmoversdelhi.indiatoppackers.in/

Packers and movers in Delhi
Packers and movers Delhi
Movers and packers in Delhi
Movers and packers Delhi

01/06/17 @ 13:32

Leave a comment

Your email address will not be revealed on this site.

Your URL will be displayed.

Please enter the phrase "I am a real human." in the textbox above.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)
January 2017
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        


The requested Blog doesn't exist any more!

XML Feeds