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 and it seems to work just fine, but I have to confirm a few things regarding the session cookie left behind on the browser.cherrypy.session.delete()
call.
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']
Confirmed reader #2!
I’m getting a lot from your series. First of all, rediscovering the mature CherryPy.
woohoo! Thanks for for the support Rick. You’ve made my year-end goal of increasing readership by 100% a reality.
Confirmed reader #3!
Can’t wait for the cherrypy restful dispatcher in gae post 🙂
And another!
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.
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.
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! 🙂
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?
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.