Google Guava's CacheLoader loadAll() vs reload() semántica

Question

Dos cosas que realmente me gustan de CacheLoader de Guava 11 (¡gracias, Google!) Son loadAll(), que me permite cargar varias claves a la vez, y volver a cargar(), me permite volver a cargar una clave de forma asíncrona cuando está "obsoleta" pero existe un valor anterior. Tengo curiosidad sobre cómo juegan juntos, ya que reload() funciona con una sola clave.

Concretamente, se extiende el ejemplo de CachesExplained:

LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder() 
    .maximumSize(1000) 
    .refreshAfterWrite(1, TimeUnit.MINUTES) 
    .build(
     new CacheLoader<Key, Graph>() { 
     public Graph load(Key key) { // no checked exception 
      return getGraphFromDatabase(key); 
     } 

     public Map<Key, Graph> loadAll(Iterable<? extends K> keys) { 
      return getAllGraphsFromDatabase(keys); 
     } 

     public ListenableFuture<Graph> reload(final Key key, Graph prevGraph) { 
      if (neverNeedsRefresh(key)) { 
      return Futures.immediateFuture(prevGraph); 
      } else { 
      // asynchronous! 
      return ListenableFutureTask.create(new Callable<Graph>() { 
       public Graph call() { 
       return getGraphFromDatabase(key); 
       } 
      }); 
      } 
     } 
     }); 

... donde "getAllGraphsFromDatabase()" hace una consulta de base de datos agregada en lugar de longitud (teclas) consultas individuales.

¿Cómo se combinan estos dos componentes de un dispositivo LoadingCache? Si algunas claves en mi solicitud para getAll() no están presentes en la memoria caché, se cargan como un grupo con loadAll(), pero si algunas necesitan actualizarse, ¿se vuelven a cargar individualmente con load()? Si es así, ¿hay planes para admitir un reloadAll()?

Answer 1

Así funciona la actualización.

refrescante en una entrada de caché pueden activarse de dos maneras:

1. explícitamente, con cache.refresh(key).
2. Implícitamente, si la memoria caché está configurada con refreshAfterWrite y la entrada es consultada después de la cantidad de tiempo especificada después de su escritura.

Si se consulta una entrada que es elegible para la recarga, se devuelve el valor anterior y se desencadena una actualización (posiblemente asíncrona). La memoria caché continuará devolviendo el valor anterior de la clave mientras la actualización está en progreso. (Así que si algunas de las claves en una solicitud getAll son elegibles para la actualización, serán devueltos a sus antiguos valores, pero los valores relativos a las llaves estarán (posiblemente de forma asíncrona) vuelve a cargar.)

El predeterminado implementación de CacheLoader.reload(key, oldValue) sólo devuelve Futures.immediateFuture(load(key)) , que (sincrónicamente) vuelve a calcular el valor. Se recomiendan implementaciones asincrónicas más sofisticadas si espera realizar actualizaciones de caché.

No creo que estemos dispuestos a proporcionar reloadAll por el momento. Sospecho que es posible, pero las cosas ya son lo suficientemente complicadas, y creo que estamos dispuestos a esperar hasta que veamos una demanda específica para tal cosa.