> > 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.
Uhh... good point, except that I don't trust the Cache code. The AUTHOR
isn't ready to put his stamp of approval on the locking/updating. I'm
running 10 hits/sec on this server, and "last write wins," which ELIMINATES
other writes, is not acceptable.
> 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.
Well, for a single, atomic lock, maybe. My two points above are the why of
my hesitancy. Additionally, what if I decide to add to my handler? What if
I update more than one thing at once? Now I've got the skeleton based on
something that somebody trusts (A:S:L:S), vs what somebody thinks is
alpha/beta (C:SASMC).
In other words....
TIMTOWTDI! :-)
L8r,
Rob
