> Once upon a time, not many moons ago, the issue of Cache::Cache came up
with
> the SharedMemory Cache and the fact that it has NO locking semantics.
It does atomic updates. Do you really need more than that? The thread you
got this from was referring to checking out a piece of data, making a bunch
of changes on it, and preventing anyone else from reading it (at least for
update purposes) until the changes are checked in. Most apps are fine with
a "last save wins" approach as long as the data is protected from
corruption.
> When
> I found this thread in searching for ways to implement my own locking
scheme
> to make up for this lack, I came upon YOUR comments that perhaps
> Apache::Session::Lock::Semaphore could be used, without any of the rest of
> the Apache::Session package.
Or you could use Apache::Session::Lock::File, which is probably easier to
deal with.
> The _session_id is used as the seed for the locking semaphore. *IF* I
> understood the requirements correctly, the _session_id has to be the same
> FOR EVERY PROCESS in order for the locking to work as desired, for a given
> shared data structure.
Only if you want to lock the whole thing, rather than a single record.
Cache::Cache typically updates just one record at a time, not the whole data
structure, so you should only need to lock that one record.
I had a quick look at your code and it seems redundant with Cache::Cache.
You're using the locking just to ensure safe updates, which is already done
for you.
- Perrin
