Opened 13 years ago

Closed 11 years ago

#2066 closed enhancement (fixed)

[patch] Make session framework backends pluggable

Reported by: hironobu@… Owned by: Jacob
Component: Contrib apps Version: master
Severity: normal Keywords: session handling
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I want a new session handler, suitable with django.contrib.auth, admin, etc... getting along with existing any modules of Django. I want session storage apart from contents database, and enhancing for load balancing and high availability. I think it is good merit for Django to have an expandable session handling system.

If there are any needs for such system, I'd like to post a patch to fulfill this feature.
(...Or maybe developer team is now implementing same function, though. ...Then sorry. (_ _) )

Attachments (2) (3.7 KB) - added by hironobu@… 13 years ago.
session handler with database and memcached, prototype.
session_engines.diff (25.6 KB) - added by John D'Agostino <john.dagostino@…> 12 years ago.
configurable session_engines

Download all attachments as: .zip

Change History (15)

Changed 13 years ago by hironobu@…

Attachment: added

session handler with database and memcached, prototype.

comment:1 Changed 13 years ago by Luke Plant

Sessions in Django are already pluggable. You simply specify a different middleware and a different app in 'INSTALLED_APPS', unless I'm missing something.

Are you suggesting that your code goes into 'contrib'? (if so you will need to clean up the code e.g. remove hard coded memcached server and similar).

What are the specific enhancements that your code brings over what Django already has?

comment:2 Changed 13 years ago by Adrian Holovaty

From what I can tell, it seems this patch allows storage of session data in memcached instead of the database.

comment:3 Changed 13 years ago by hironobu@…

Yes, adrian. Sorry for my poor explaining and dirty code...

I picked 'django.contrib.sessions.*' module, and tried to make it possible to use memcached or database selectively.

If possible, I'd like to propose "SESSION_ENGINE" element in, so that we can select session storage from it - instead of hardcoded "_type = 'memcache'", as lukeplant pointed out.

But I didn't prefer to touch so much code - any other than the module originated from 'django.contrib.sessions.*', I decided to finish within it.

This is the reason why I hardcoded it.

comment:4 Changed 13 years ago by Adrian Holovaty

Summary: pluggable session handler[patch] Make session framework backends pluggable

comment:5 Changed 13 years ago by anonymous

any chance of getting this into contrib?

this will be one step do not requiring a database for django to work

FWW I just implemented the same thing (just to the cache) here

comment:6 Changed 12 years ago by Simon G. <dev@…>

Triage Stage: UnreviewedDesign decision needed

Changed 12 years ago by John D'Agostino <john.dagostino@…>

Attachment: session_engines.diff added

configurable session_engines

comment:7 Changed 12 years ago by John D'Agostino <john.dagostino@…>


I'm actually +0 on this, after reading lukeplants comment.

Notes on the patch:

adds SESSION_ENGINE setting, and database, cache, file based session backends.

cache backend based on django.core.cache - although i do have code for a pure memcache session store.

to implement your own session engine, subclass SessionBase and provide load,save,exists and delete methods

updated tests

updated docs (although they need improvement) hasn't been modified to maintain backwards capability; although all functionality is now in SessionBase

Comments always welcome. Willing to improve the patch or answer any WTFs in the code.

comment:8 Changed 11 years ago by anonymous

A backend session framework shouldn't lose data when a memcache node goes down. I think that memcache could be used to speed up the select operations from the session, but all inserts should go to both memcache and to the db session backend.

Instead of a different backend, I would propose an extension to the existing backend to store the session data in memcache in addition for improved performance in high-read low-write situations. Perhaps a person could add an option to disable the database store if session data integrity is of no consequence and the application can tolerate logging all users out on a node failure.

comment:9 Changed 11 years ago by anonymous

I think with Session.objects.cache() method implemented, this patch becomes less attractive

comment:10 Changed 11 years ago by Yuri Baburov

Owner: changed from nobody to Yuri Baburov
Status: newassigned

comment:11 Changed 11 years ago by Jacob

Owner: changed from Yuri Baburov to Jacob
Status: assignednew

comment:12 Changed 11 years ago by Jacob

Status: newassigned

comment:13 Changed 11 years ago by Jacob

Resolution: fixed
Status: assignedclosed

(In [6333]) Fixed #2066: session data can now be stored in the cache or on the filesystem. This should be fully backwards-compatible (the database cache store is still the default). A big thanks to John D'Agostino for the bulk of this code.

Note: See TracTickets for help on using tickets.
Back to Top