2009/12/16 Damjan <[email protected]>:
>> > Beaker + memcached backend?
>>
>> But does it have cross process/cross system session locking for life
>> of request with session open?
>
> You mean like,
> - reading the session from mc,
> - changing something
> - saving a new copy to mc
> and if this happens concurently?
>
> From what I see in the code Beaker should support that, but maybe a
> clarification from the author would be needed.
>From what I see in the code I don't believe it does, or at least that
isn't the intent. Quoting code:
def load(self):
"Loads the data from this session from persistent storage"
...
self.namespace.acquire_read_lock()
try:
...
finally:
self.namespace.release_read_lock()
if timed_out:
self.invalidate()
Note how it releases the only lock it got when reading session.
Anyway, that is the default behaviour at least. It means no lock is
held for whole period of request that the session is being used and
possibly modified then written.
To have it held for period of whole request, you need to lock it
explicitly. However, the comments in code for doing that are saying
that those functions should be removed as a TODO item.
# TODO: I think both these methods should be removed. They're from
# the original mod_python code i was ripping off but they really
# have no use here.
def lock(self):
"""Locks this session against other processes/threads. This is
automatic when load/save is called.
***use with caution*** and always with a corresponding 'unlock'
inside a "finally:" block, as a stray lock typically cannot be
unlocked without shutting down the whole application.
"""
self.namespace.acquire_write_lock()
def unlock(self):
"""Unlocks this session against other processes/threads. This
is automatic when load/save is called.
***use with caution*** and always within a "finally:" block, as
a stray lock typically cannot be unlocked without shutting down
the whole application.
"""
self.namespace.release_write_lock()
So, the intention seems to be to not support the ability to have
locking be for life of request which needs to be able to update
session data, even though lock()/unlock() method allow for that at
present.
Anyway, who actually reads code/documentation properly to know they
would have to call lock() explicitly to get what was default behaviour
of mod_python.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
