CacheLoaderTask.java

// A task that is invoked by multiple threads, once for each entry 
// Implementations MUST be threadsafe, as processEntry will be invoked concurrently.
// Ideally, don't maintain state in your implementation!
public interface CacheLoaderTask {  
  void processEntry(LazyInternalCacheEntry entry, TaskContext context);  
}

// Very similar to an InternalCacheEntry, except deserialisation of contents happens lazily, as and when requested.
// Also, direct access to the underlying byte buffers that back this entry are exposed.
public interface LazyInternalCacheEntry {
  Object getKey();
  InternalCacheValue getInternalCacheValue();
  /**
   * Same as getInternalCacheValue() but doesn't de-serialize the value.  Only the metadata and timestamps.
   */
  InternalCacheValue getSparseInternalCacheValue();
  ByteBuffer getKeyBuffer();
  ByteBuffer getInternalCacheValueBuffer();
}

public interface TaskContext {
  /**
   * If invoked, will *attempt* a best effort to stop processing further tasks.  Tasks already started will not be stopped.
   */ 
  void stopProcessingEntries();
  /**
   * A best effort calculation on the number of entries processed, including the current entry.  Susceptible to race conditions and may not be absolutely accurate.
   */ 
  int getNumberOfEntriesProcessed();
}

• getSparseInternalCacheValue: I think a better name would be getMetadataBuffer():ByteBuffer. But why do we need this function for?
• Not sure about the name LazilyInternalCacheEntry: I don't think the fact that it's internal brings any useful info to the party. Actually I think InternalCacheValue should be renamed to CacheValue as well. And the MvccCaceEntry -> ContextEntry. IMO a clear simpler name for LazilyInternalCacheEntry is CacheEntry.
• also byteBuffer bit should be moved in a different interface and only implemented in a next iteration of the API - there is an ongoing discussion on the -dev about it.
• I imagine that TaskContext.getNumberOfEntriesProcessed was added to support the situation when we're only loading N entries during the preload? If that's the case I'd rather count the processed entries myself in specific CacheLoaderTask implementation that does the preload. All other CacheLoaderTask implementations I'm aware of don't need this functionality so we'd end up counting entries unnecessarily.

Here's my API suggestion: https://gist.github.com/mmarkus/6195428