Re: [Flamerobin-devel] MetadataItem locking

[Milan B. <albis@EUnet.yu>]

Michael Hieke wrote:
> If another object observes, then it will query information from our 
> changed object, in its update() method.  It will call our object's 
> getter methods, and only inside of them information will be reloaded, if 
> necessary.  This (lazy evaluation) is vital, it's the key to minimal 
> updates.

Ok, agreed.

>> Looking at all this, perhaps we need a 3-state flags for objects' 
>> properties which load at run time. Currently we have something like:
>> bool descriptionLoadedM. Maybe we should have flag with three
>> states: notLoaded, loaded, needsReload. The "needsReload" would mean
>> that that part of object is "invalid" and needs to be loaded when
>> lock is released. The difference versus "notLoaded" is in the fact
>> that properties that are "notLoaded" yet were not needed, so no need
>> to reload. Also, releasing a lock on object that has some
>> "needsReload" properties would mean that notify() needs to be called
>> (observer pattern).
> 
> There is no real difference between notLoaded and needsReload.

If we don't mix locking with invalidating, then yes, there is no 
difference. So, let me get this clear: When SQL parser finds a 
statement, and either

a) updates the object directly
b) sets the somethingLoadedM flag to false

and leave the rest to observer pattern. Yes, that does sound like the 
most natural and efficient way, so I agree with you.

>> - checking for lock should check all parents up to the root node
> 
> I don't see much benefit over the other way around.

I'm not sure I understand what you mean by that?

>> - releasing the lock should call update() for the current object + all 
>> child objects recursively
> 
> You mean notifyObservers(), right?

Yes. Sorry about that.

> Anyway, IMHO it's better to let each 
> object decide for itself what to do after the lock has been released. 
> And propagating the lock counter to all children will take of the 
> recursion you mention.

Ok.

>> - 3-state flags should be used anyway
> 
> I disagree.

I agree with your disagreement :) I take the 3-state flag idea back, 
unless a strong case for it shows up.

-- 
Milan Babuskov
http://www.flamerobin.org