Code

Opened 8 years ago

Closed 7 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: UI/UX:

Description

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)

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

Download all attachments as: .zip

Change History (15)

Changed 8 years ago by hironobu@…

session handler with database and memcached, prototype.

comment:1 Changed 8 years ago by lukeplant

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 8 years ago by adrian

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

comment:3 Changed 8 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 settings.py, 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 8 years ago by adrian

  • Summary changed from pluggable session handler to [patch] Make session framework backends pluggable

comment:5 Changed 8 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  http://svn.zyons.python-hosting.com/trunk/zilbo/common/sessions/middleware.py

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

  • Triage Stage changed from Unreviewed to Design decision needed

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

configurable session_engines

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

Discussion:
http://groups.google.com/group/django-developers/browse_thread/thread/fd314ad62417db98/8e614855debfaee1

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)

models.py 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 7 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 7 years ago by anonymous

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

comment:10 Changed 7 years ago by buriy

  • Owner changed from nobody to buriy
  • Status changed from new to assigned

comment:11 Changed 7 years ago by jacob

  • Owner changed from buriy to jacob
  • Status changed from assigned to new

comment:12 Changed 7 years ago by jacob

  • Status changed from new to assigned

comment:13 Changed 7 years ago by jacob

  • Resolution set to fixed
  • Status changed from assigned to closed

(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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.