From: Milan B. <albis@EUnet.yu> - 2005-09-27 17:45:14
|
Nando Dessena wrote: > I can't see big advantages/disadvantages either way, so I'd stick > with the "natural" approach of locking single items. Delegating > another entity to keep a list of locked objects, which is basically > putting object state outside of the object itself, might have its > merits but the move needs to be justified. For mere locking we don't need to "keep a list". We need to keep a list if we wish to integrate the "invalidation stuff" into locking, and make all that a single mechanism. The real question is do we want that. Here's the idea. Let's say we run into statement that changes table's description and it needs to be re-loaded. The table would ask for lock and proceed to update the description. The lock manager would either give a lock, or not. In case it does not give a lock, it would put table "on hold". Later, when lock is released it should "call" the table, and let it reload the description from database. The information that description needs to be loaded should be in the table object itself, not in lock manager. As you can see, my idea could be implemented even without the list of object. Once global lock is released, just call each object and let it update itself if needed. 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). > So I'd prefer the more natural and > flexible solution, In case we go for that, I have few ideas: - checking for lock should check all parents up to the root node - releasing the lock should call update() for the current object + all child objects recursively - 3-state flags should be used anyway I'm still not sure which method is better, as I can't anticipate what the future needs will be. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |