This page describes current problems with the recomputing and caching in Cultivate and propose a possible solution that makes caching, query scheduling and notification explicit. The solution is made of the components Repository (as cache) and Refresher (as scheduler).

→ Rework to the notion of deferred query execution. Calling query.execute() should tell the prologQueryExecutor to schedule this query. he PrologQueryExecutor should queue query requests and only execute them, when factbase has been constructed.

→ Rework Builder (and UpdateJob? or delete this) to do the work, recompute all cached queries (smells, metrics, other queries) and then notify all interested clients. All Views (DiagramViewPart, ResultViewPart, CloudViewPart) should register for certain notification-topics (and content) at a central place - Repository in cultivate.core (sounds like an Event Bus with Pub/Sub).

→ Add an action into the ui to request a complete clear and rebuild of the cultivate cache. The automatic refresh sometimes does not work, when the factbase was recreated.

→ With this described reworking, we should also explicitly have a look at this and call an cache rebuild only once.

Further, Cultivate restarts the factbase upon switching between projects. Is this because of JT or is the factbase still valid in memory, so no rebuild is needed?

dsp: What does 'restarting' the factbase mean?

Repository and Scheduler run outside the UI thread, notifications are the border into the ui thread - clients have to take care of reading and updating their views in ui thread. All computation should go in the other thread, issued by scheduler.

This way, asynchrony is made explicit within the event bus inside the repository. Borders to other threads are also explicit, as all of them may only be located inside the handlers for notification events (part of UI controllers in the future). Transition to ui thread is explicit there.

The solution depends upon further reworking / splitting detector into the concept of a query (is already there) with sub-concepts: smelldetector, metric, other special queries

Writing a simple event bus with pub/sub is easy. Adding correct threading into it and writing the queuing for the scheduler is harder.

• One design goal of the current implementation was to re-execute queries only when necessary, so that no query is executed in case the developer works with the Java perspective and has no Cultivate view open at the moment.
• AFAIUnderstand your suggestions are a more precise description of the restaurant metaphor, so that I aggree with the general direction. (Scheduling the architecture changes is of course up to the planning game.)