> 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).
What I meant was that since there is a separate lo
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
> > ac
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
> r
On Sat, 4 Aug 2001, DeWitt Clinton wrote:
> Excellent, this is the right approach. Sounds like I
> need to update the documentation to say that "objects
> retrieved from the cache are not 'live,' they are
> clones. If you want to save modifications, remember to
> store them again in the cache."
On Sat, Aug 04, 2001 at 03:06:37PM -0400, DeWitt Clinton wrote:
> To quote Jimi Williams, "manager's decision."
Yes, I know it is Jimy Williams. See what happens when a lifelong Red
Sox fan relocates down to NYC? We start losing our minds... :)
-DeWitt
On Sat, Aug 04, 2001 at 10:34:34AM -0700, brian moseley wrote:
> ps: i've modified my code to 1) only get once per request
> and 2) set at the end of each request. the net effect is
> that stuff works as expected. i'm reasonably happy with the
> current state of affairs, but...
Excellent, this i
On Sat, Aug 04, 2001 at 09:17:21AM -0700, brian moseley wrote:
> could this be because i'm only ever doing one set, at
> session creation time? since i'm using a memory cache, i
> didn't expect to have to call set every time i modify the
> cached data.
Yup. That would be it. Please see my resp
ps: i've modified my code to 1) only get once per request
and 2) set at the end of each request. the net effect is
that stuff works as expected. i'm reasonably happy with the
current state of affairs, but...
i don't like having to explicitly call set to force
modifications to be written to the c
On Sat, 4 Aug 2001, DeWitt Clinton wrote:
> Can you check the actual data contained within the
> object? If I understand things right, there is a chance
> that the data itself is indeed the same. However, the
> instance containing the data (in your case, an instance
> of Wombat::Core::Session)
On Fri, Aug 03, 2001 at 11:33:43PM -0700, brian moseley wrote:
> i'm observing some behavior using Cache::Cache that seems
> odd, altho it may be due to my faulty understanding of how
> the interface works.
Can you check the actual data contained within the object? If I
understand things right,
i'm observing some behavior using Cache::Cache that seems
odd, altho it may be due to my faulty understanding of how
the interface works.
i'm using Cache::MemoryCache to manage a cache of session
objects in a non-forking apache process. once i've initially
called set to store a session object us
11 matches
Mail list logo
