At 05:44 PM 8/5/2001 -0400, Perrin Harkins wrote:
>on 8/4/01 1:34 PM, brian moseley at [EMAIL PROTECTED] wrote:
> > also, has there been any thought given to locking cached
> > items? when i'm using a shared cache with multiprocess
> > apache, the opportunity exists for multiple requests to
> > access a single session simultaneously, which can lead to
> > races. which i'm happy to ignore for now but would be nice
> > to eventually prevent.
>
>Gunther's Extropia stuff includes optional support for sessions that lock in
>the way you're describing, but I've never seen any other session
>implementation that did it this way. It seems that the session pattern is
>generally used for transient data where last-save-wins is fine as long as
>the integrity of the data is protected during the actual writes. If you
>need fancier locking, you could try ripping the lock stuff out of
>Apache::Session.
>
>- Perrin
My impression was that the locking in Apache::Session is a one-time lock so
it just fixes data integrity issues. So I am not sure if it is fancier than
Cache::Cache unless Cache::Cache has no locking at all (or no concept of
lock choice).
I was really interested in abstracting the locking API for
Extropia::Session because it was an interesting challenge and frankly at
the time I *thought* that Apache::Session did it, so I wanted to match it.
In addition, the motivation for Extropia::Session was to match the Java
Servlet Session spec so I wanted to make sure that whatever protections
were provided by Java, I would have in Perl multiprocessing environment.
The latter being fairly difficult to emulate exactly.
In the end, I don't think I have actually written any applications that
would cause two session updates to occur at the same time, so it might have
been overkill.
I am lately thinking of session as a means to store very transient stuff
but then real persistent application data such as cart data from a web
store should be stored in a real data storage with real multi-user locking
with the session id as a mere key to that database.
I guess it just depends on your scenario. I would be curious to hear about
some real world (as opposed to academic) scenarios about it being an issue.
Later,
Gunther
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
