This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: modperl@apache.org Subject: Re: odd behavior with Cache::Cache From: Gunther Birznieks <gunther@extropia.com> Date: Mon, 06 Aug 2001 09:45:17 +0800 At 05:44 PM 8/5/2001 -0400, Perrin Harkins wrote: >on 8/4/01 1:34 PM, brian moseley at bcm@maz.org 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. eXtropia - The Open Web Technology Company http://www.eXtropia.com/ ===