CherryPy Sessions on GAE

25 Oct

My only confirmed regular reader, Sal, notified me of a potential problem with using CherryPy on GAE which stems from the multi-threaded nature of CherryPy and the single threaded ways of GAE. It was first noticed in trying to take advantage of the cherrypy.session facilities. In short, you can use cherrypy.session to store session values in the memcached backend, but I am still trying to determine whether the session information is deleted from the store, even on a cherrypy.session.delete() call. and it seems to work just fine, but I have to confirm a few things regarding the session cookie left behind on the browser.

The original comment is here, for the curious.

If you would still need sessions and just can’t wait for the bugs to be ironed out, here is how you go about using cherrypy.session. In your main.py:


from google.appengine.api import memcache
# patch sys memcache module locations to use GAE memcache
sys.modules['memcache'] = memcache

You’ll need these configuration options defined and applied to the tree.mount() in the main():


cf = {"/":{'tools.sessions.on':  True,
            'tools.sessions.storage_type': "memcached",
            'tools.sessions.servers': ['memcached://'],
            'tools.sessions.name': 'hello_gb_session_id',
            'tools.sessions.clean_thread': True,
            'tools.session.timeout': 10, # ten minute session timeout, not sure if this works
            }}
  app = cherrypy.tree.mount(MyClass(),config=cf)

Then in your methods you can get and set session variables at will like so:


def index(self):
    cherrypy.session['msg'] = "Hello World!"
    return cherrypy.session['msg']

10 Responses to “CherryPy Sessions on GAE”

  1. Rick Thomas October 25, 2008 at 3:32 pm #

    Confirmed reader #2!

    I’m getting a lot from your series. First of all, rediscovering the mature CherryPy.

  2. delagoya October 25, 2008 at 7:20 pm #

    woohoo! Thanks for for the support Rick. You’ve made my year-end goal of increasing readership by 100% a reality.

  3. Dado October 26, 2008 at 4:41 am #

    Confirmed reader #3!

    Can’t wait for the cherrypy restful dispatcher in gae post 🙂

  4. Owen October 26, 2008 at 8:32 pm #

    And another!

  5. delagoya October 27, 2008 at 1:17 am #

    Oh, you guys are making me blush.

    Seriously though I appreciate the support. Don’t hesitate to point out mistakes or suggest topics to discuss, since I am basically learning CherryPy and GAE as I write this blog. Chance of errors, or missing essential points, is highly probable.

  6. Nick Johnson October 27, 2008 at 11:01 am #

    Another confirmed reader. I suspect if you check your hit logs for RSS readers, you’ll find you have more readers than you suspect – we’re just lurkers.

  7. Robert Brewer October 27, 2008 at 7:00 pm #

    I had to double-check that the memcache session test actually passed, because I seemed to recall it didn’t work yet. But all the test pass. Thanks for promoting it! 🙂

  8. Sal October 29, 2008 at 5:01 am #

    I’m not sure how memcached works but the memcache API documentation in GAE suggests that data in memcache has a possibility of being flushed by Google’s servers due to memory pressures. This makes me wonder if using CherryPy’s sessions with memcache (alone as storage) might be a problem. One practical implication might be that potential customers using a shopping cart will get annoyed (and possibly leave) by having to re-add their items/orders because the session was lost under heavy load on Google’s servers. Is there a way around this?

  9. delagoya October 29, 2008 at 4:55 pm #

    Possible missing data is true of any non-persistent storage, including memcache. You only have so much data that can fit in the specified storage space. It would be nice if there was a published SLA for an app’s memcache quota, but I don’t think there is.

    Even so, I don’t think this is going to be a problem as long as you are aware of it and code in defense. For high-priority data, you can fetch re-insert into the memcache store to renew the timeout, since I believe memcache is first-in-first-out when it comes to garbage collection.

    Another possibility is to use a cookie store for your important data, but you risk all sorts of security concerns if you are not careful.

    I would not recommend Datastore for the session data. To much change for it to scale well.

    Finally, if it is really that important a data item, you can contract out the service to a persistent store not on GAE, like AWS SimpleDB.

Trackbacks/Pingbacks

  1. Google AppEngine investigations - various links « LSD::RELOAD - March 1, 2009

    […] cherrypy session for GAE – using memcache. Looks reasonable, though memcache isn’t that great as a session store. […]

Comments are closed.