perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gunther Birznieks <>
Subject Re: Cache::Cache locking
Date Sun, 23 Dec 2001 07:33:44 GMT
At 10:55 PM 12/22/2001, brian moseley wrote:

>Apache::Singleton::Server got me thinking about Cache::Cache
>and locking again. if i'm going to have a server-global
>object, i am going to need to protect against multiple
>processes updating it simultaneously, right?
>we've already talked about this in regards to sessions. most
>folks seem to feel that "last one wins" is sufficient for
>session data. but what about for objects for which this
>policy is not good enough?
>if locking is necessary in some instances, even if we can
>only contrive theoretical examples right now, how might it
>be done in a performant way, especially for objects that can
>be modified multiple times while handling a single request?
>seems like if you synchronized write access to the object
>and caused each process to update its local copy after each
>modification, you'd have a hell of a lot of serialization
>and deserialization going on in each request.

Well, I think it depends on the situation. In Extropia::Session what we did 
was set up policies. The default policy is similar to Apache::Session. But 
we allow stronger policies if another application requiring more stringent 
care on the session data shares the user session handle and underlying data 

We ended up separating the concept into two seperate policies: a cache 
policy and a lock policy. Cache policies are things like no cache, cache 
reads, cache reads and writes (so nothing gets written until the object is 
destroyed or flushed manually). Lock policies include no locking (last 
wins), data store (the whole cache is locked because attributes may depend 
on each other), and attribute level locking (integrity is only maintained 
on the attribute write level).

These "policies" effect a general policy of how Extropia::Session works.

I think there are more sophisticated ways of doing an API than an arbitrary 
policy of course. In some cases, locking is something that should be 
settable directly. For example, I mentioned some attributes may depend on 
each other.

For example, let's say a session stores an attribute indicating your 
savings account and another indicating your checking account. Obviously to 
perform a funds transfer within your session you'd want to wrap both 
attribute changes inside of a lock.

Of course, this sort of lock can be separate from the session cache. But 
ideally in order to interact well with previously set session policies the 
locking that is automatic should be similar to the locking that is explicit.

I think if I had to do it over, I would probably not have implemented my 
own Session and reused one of the newer caching mechanisms. One of the 
reasons I didn't go with Apache::Session is that I needed more 
sophistication than Apache::Session provided but I did like Apache::Session 
enough that we wrap around it and provide the extra session features I wanted.


View raw message