Class RestCacheEviction

java.lang.Object
ubic.gemma.cli.util.RestCacheEviction
public final class RestCacheEviction extends Object
Tells the running gemma-rest to drop what a CLI rebuild has just made stale.

A rebuild command can evict the Hibernate query regions in its own JVM — and every one of them does — but gemma-cli is a separate process. gemma-rest learns nothing from that eviction and goes on serving the rows it cached before the rebuild ran. Twice this has looked exactly like the rebuild having failed: reference subject role kept serving 1,967 deleted rows on 2026-08-17, and on 2026-08-18 a search read zero relations for MEC-1 against a table that held one, after the CLO rebuild had gone in correctly.

Both regions, not just the first. default-query-results-region holds the cached rows; default-update-timestamps-region is what Hibernate consults to decide whether a cached query is still valid. Flushing the rows while leaving the timestamps can repopulate the cache from a timestamp asserting the table has not moved.

🛑 Failures are reported, never swallowed. The pre-existing updateEe2c ping discarded its response and logged success unconditionally, so a refresh that 404'd or hit the wrong host was indistinguishable from one that worked.

  • Field Details

    • AFTER_REBUILD_REGIONS

      public static final List<String> AFTER_REBUILD_REGIONS
      The regions a table rebuild leaves stale.

  • Method Details

    • evictAfterRebuild

      public static boolean evictAfterRebuild(ubic.gemma.core.util.GemmaRestApiClient client, org.apache.commons.logging.Log log)
      Evict the after-rebuild regions on the configured gemma-rest host.

      Never throws: a rebuild that wrote its rows correctly has done the important half, and failing the command afterwards would misreport that. The log says plainly what did not happen and what to run by hand.

      Returns:
      true if every region was evicted