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. > >thoughts?
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 store. 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. Later, Gunther