Description Michael Scharf 2004-06-25 09:13:33 EDT

Summary
-------
If many update events are sent for the same node in succession, Decorators of 
the given node are not called as needed. The reason for this is, that the 
DecoratorScheduler's cache may get filled with outdated information since old 
(outdated) requests are still in the queue when the cache gets cleared.
A correct implementation should modify DecoratorManager.update() and the 
LabelProviderChanged event, so that the DecoratorScheduler's cache
is not cleared immediately but the cache-clear-request is enqueued as an event 
just like the decoration events themselves. Then, the DecoratorScheduler can 
clear the cache at the right time, so that order of events is as they were 
received.


Details
-------

In Eclipse 3, the DecoratorScheduler runs in a separate thread. It gets 
requests to decorate model elements scheduled in a queue. Once a decoration 
request is executed, the result is put into a cache: if the model node does 
not change, the subsequent requests will take the decorator result from the 
cache.

Now it is a valid use case to have elements decorated regardless of the state 
of the original model. For instance, assume a (large) collection of nodes 
where you want to decorate one of the nodes as being the "default node". The 
default can change even if the nodes themselves do not change..

Since the nodes themselves do not change, a Decorator implementation must not 
use the DecoratorManager's internal cache, since it only takes into account 
the model's contents but not any external information that's only known to the 
decorator (like the given default). But we haven't found a way to disable the 
cache; therefore, when the Decorator gets notified that the default node 
changed, it sends the DecoratorManager a "clear cache" request for the given 
node. This should make sure that the next refresh leads to a decorate event, 
which can then correctly load the overlay image for the decorated node.

Now here is the bug: The "clear cache" request is executed in the caller's 
thread, but it must be executed in the decorator's thread to make sure that 
the order of "decorate" and "clear cache" events is the same as they were 
originally sent.

If this is not observed, the following happens: there may be lots of decorate 
events in the DecoratorManager's queue, some of them may point to the same 
node. If the "clear cache" is done immediately, the old (outdated) events from 
the queue will lead to putting old
(outdated) information into the cache again, and the "clear cache"
event does not lead to the expected result (making sure that new enqueued 
events will work without cache).

Suggested solution 1: "clear cache" events must be en-queued just like update 
events, and executed by the DecoratorManager in it's own thread and not in the 
caller's thread.

Suggested solution 2: When a Decorator is registered with the 
DecoratorManager, the given decorator should have a property that instructs 
the DecoratorManager not to use any cache. Such a cache-less decorator will 
then be good for decorations that do not depend on the model's state.