DiskLruCache2

Goals

• Read while writing.
• Avoid I/O in synchronized blocks.
• Only one file per entry.

API sketch

class DiskLruCache2 {
  Entry get(String key);
  Entry put(String key, ByteString metadata, Source upstream);
  // ... plus methods for sizing, trimming, iterating, etc.

  static class Entry {
    ByteString metadata();
    Source newSource();
  }
}

Implementation sketch

Each entry that is being written has these sources and sinks:

• The upstream source passed into put(). This has a logical cursor starting at 0, representing the next byte to read.
• The file sink. Data read from upstream is written to the file sink. Its cursor starts at 0 and is incremented when a flush completes successfully. Its cursor represents that last byte that is safe to read from the file.
• The sources created by calls to newSource(). On each attempt to read it will read from the file (if its cursor is lower than the file cursor) or from the network otherwise. If it reads from the network it is responsible for writing to the file.

Readers cooperate with synchronization, with only one reading from upstream at a time. We should also add a buffer to contain up to N bytes preceding the upstream source’s cursor. Readers may prefer to read from this buffer instead of from the file for better performance. Also this makes it possible to reduce flushes to the file system.

Notes

• What happens when a FileInputStream reads the last byte of a file? Does it eagerly EOF? Or does it continue to read bytes if further bytes are later written to the file?
• The current DiskLruCache has CLEAN and DIRTY entries in its journal. We should do likewise. An entry can be made clean after the upstream source on a put reaches EOF. This requires a last flush to the file.
• We want to be able to put() a new entry when an existing entry is already in place. This is necessary when a conditional GET misses.
• We may also want to be able to put() new metadata without updating the rest of the cache. This might motivate putting the metadata ByteString at the end of the file.

[ScottPierce]

@swankjesse Is there any intention to make an OkHttp Cache that is only in-memory or make the persisted data encrypted so as to better handle using the cache with secure data?

[ScottPierce]

What a fantastic benefit of the FakeFileSystem. Thanks for the suggestion!