nasa/mct — pull request #232 by VWoeltjen (2013-12-11 17:46:50+00:00)
Title: [Persistence] Reduce lost responsiveness due to latency

A few specific cases of unresponsiveness identified in nasa/mct#111 are addressed here.

* Avoid creating extra copies of the Info View when first selecting a component in the Browse area
* Use a caching solution for cases where custom queries previously circumvented the caching solution for user objects
* When looking up bootstrap components, a custom query is invoked. This remains, but the results are cached (and sometimes refreshed) as component ids; the normal getComponent operation can then be used to look these up, utilizing the component cache.
* When looking up all users, cache results so that subsequent calls can return quickly. List of all users is refreshed on a background thread.

In both cases, caching is implemented using a "Step-Behind Cache" - a cache that is always one step behind the ground truth of the database. This approach returns the last available answer (quickly), then looks up the current answer on a background thread so that it will be available on the next invocation. In the cases above, this is considered acceptable behavior: User lists and bootstrap component sets rarely change, and while these changes should show up within a user's running instance of MCT, having their appearance delayed by one operation is unlikely to be noticed, and there do not appear to be any cases where this would cause an error.

This is taken as favorable over the two clear alternatives:
* Get the latest results every time, which always involves a round trip to the database and is subject to network latency. This would force user code (such as views, policies, etc.) to either avoid making these requests or to do so asynchronously in order to avoid blocking the UI - in short, the issue would need to be addressed in many places. This solution is taken to impose an undue burden in the context of plug-in support.
* Poll for updates in the background. This approach works well for active components, but for rarely-changing objects such as the user list or bootstraps this creates a lot of ongoing overhead in terms of network traffic, and would additionally likely require changes to the database schema (to timestamp changes to the user table.) Additionally, these query results are still at least as out of data as the polling frequency, which may be higher or lower than that practically achieved by the step-behind cache.

Wrote or re-wrote unit tests (Y/N): Y*
Ran entire suite of unit tests successfully (Y/N): Y
Verified bug fix with the described replication steps or verified the implementation meets the requirement cited (Y/N): Y (partial)
Code coverage requirements satisfied (new code=80%, changed code=at least as high as existing) (Y/N): Y
Code review date and attendees: Self-review by pull request
Describe potential impact on other areas of the code: Info View, Inspector
Describe any test prerequisites for this fix (e.g., restart the database): Test with high latency in database connection
For bugs marked "Regression - Yes", describe the cause of the regression: N/A
Did you modify any pom.xml file? If yes, did you thoroughly document your changes and reasons? N

Unit test written for new class. Tests for specific issue do not seem feasible due to role of timing and specific conditions required to reproduce (at minimum, this would inflate duration of test suite)

Issue nasa/mct#111 is not presumed to have been wholly solved by this fix, although specific cases identified in the issue and in comments are addressed. Some known cases of problematic latency still exist and will be noted in the issue.