nasa/mct — pull request #211 by VWoeltjen (2013-10-09 19:00:29+00:00)
Title: [Persistence] Avoid polling uninitialized database

Database persistence uses the current database time when polling for changes (on a background thread), which it gets by reading the current timestamp from the database. Query used to read this looks up based on some component owned by the user - however, there may be no such object in the special case where there is no prior database and bootstrap components have not been injected yet. This results in the exception seen in nasa/mct#198

Changes here address this problem on multiple fronts:
* First, don't start polling the database immediately (wait one polling interval); in principle there should not be any stale components 0ms after startup anyway
* Second, catch the exception which occurs when database time cannot be read and return null. (A null value is already used by the method in question to indicate "no timestamp available" in other circumstances, and is checked for by callers, so this is consistent.)

Wrote or re-wrote unit tests (Y/N): N*
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
Code coverage requirements satisfied (new code=80%, changed code=at least as high as existing) (Y/N): N*
Code review date and attendees: Self-review (no second developer available)
Describe potential impact on other areas of the code: Persistence, component refresh
Describe any test prerequisites for this fix (e.g., restart the database): Run without any prior database using a Derby configuration (default for platform build)
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

Note: No unit tests written, as issue is timing-related and there is no apparent test case to reproduce that reliably