Modify session data outside of session

6 views
Skip to first unread message

Ted G

unread,
Sep 17, 2010, 2:05:10 PM9/17/10
to gae-sessions
Hi David,

Great little package you've put together here.

I have an application where I am using sessions to cache user data
that may change as a result of actions by another user. Caching the
user data is critical to performance of the app. I was thinking of
taking the following approach:

- on creating a new session for user A store the resulting sessionID
in the DB as part of user A's data.
- if user B modifies cacheable data of user A:
--- retrieve session data for user A using sessioniD stored for user A
--- remove cached data from user A session which will force that data
to be re-read next time user A session is accessed.

Looking at gaesessions, it was not clear to me how I could use the
Session object outside of the current user's session for performing
the tasks above. My thought was just to create a helper function
directly accessing memcache and SessionModel (combining code from the
__retrieve_data and save methods of the Session Object). But I thought
I would ask first if there is an easier way using the existing library

dound

unread,
Sep 17, 2010, 8:28:12 PM9/17/10
to gae-sessions
This is a bit tricky because concurrent access to a single session
could cause problems. Consider this:

1) User A makes a request and their session data is retrieved.
2) User B retrieves session data for User A.
3) User A makes changes to their session and saves it.
4) User B makes changes to the retrieved session data for user A - but
the session being changed is stale! (it was retrieved before User A
saved changes to their session).
5) User B saves the changes made to User A's session - wiping out the
changes User A just made to their own session in (3).

A safer approach would be to store the shared data under its own
unique memcache key. If you can segment the shared data such that it
only has a single writer, then you don't even need to worry about
concurrent access to it. On the other hand, if the shared data may be
accessed for writing by more than one request/user at a time, then you
could protect it from concurrent modification with a memcache
"lock" (use memcache.add() to try to acquire the "lock", and
memcache.delete() to free it).

~ David
Reply all
Reply to author
Forward
0 new messages