Re: [SQLObject] Cache Lock Problems

[Ian B. <ia...@co...>]

On Mon, 2003-04-14 at 17:08, Luke Opperman wrote:
> Quoting Ian Bicking <ia...@co...>:
> 
> > On Mon, 2003-04-14 at 14:52, Luke Opperman wrote:
> > ...
> > Hmmm... purge, delete, etc, aren't well thought out yet.  I.e.,
> > they don't ensure consistency.
> 
> Hmm. What consistency should happen here? The problem we identified
> was _not_ a thread/race-condition, but a single-thread issue that can
> be identified completely separate from SQLObject. I've attached a
> test script I used, that does the insert/purge/retrieve steps I
> mentioned last time, directly on a CacheSet.

Yes, the whole destroy/purge thing is broken.  That's why I didn't
document it :)  I'll have to take some time to read it over more closely
and probably reimplement it.

> > Actually there shouldn't be a locks there -- if None is returned
> > from get(), the caller is responsible for creating an object and
> > putting it into the cache with put(). Otherwise you can't be sure
> > that two objects won't be created.
> 
> I'm confused. Are you saying it is the caller's responsibility to lock
> a get/fail/put cycle? I can understand that, in which case an
> alternate fix to Cache.py is to remove all locking. Doesn't change
> the fact that locking is very broken in the currently released file,
> singlethreaded or not. :)

No, there's no lock required if the object is already in the cache. 
There's only a lock required if the cache lookup fails.  That's why the
caller doesn't do the locking, the Cache instance does. 

> Or is the intention that Cache is expected to handle the locking, but
> by the caller executing get and put in a specific order (this is more
> like the code appears to be...). Not sure I agree with this plan, and
> I'd definitely prefer it was more explicit
> (CacheSetInst.createLock.acquire()/release() by the caller?).

Yes, that's it.  But like I said, the caller doesn't know if a lock is
required.

  Ian