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
