Niklas Edmundsson wrote:
However, I don't see how you can do a lockless design with multiple files and an index that can do:* Clients read from the cache as files are being cached. * Only one session caches the same file. * Header/Body updates. * No index/files out-of-sync issues. Ever.
Thinking about this some more I do see a race during purging - a cache thread could read the header, the purge deletes header and body, and then the cache thread reads the body, and interprets the missing body as "the body is still coming".
One possible (and reasonably simple) solution would be to cache the header and body in a unique directory - the directory name becomes the key, and the entry is either cached completely / still being cached if the directory exists. This assumes it's possible to atomically delete directories.
Another option is to version the filename of the body based on a key in the header. In other words, in the header, called <key>.header, is a version number <timestamp>, meaning there should be a body called <key>.<timestamp>.body. A replacement cached entry therefore cannot stomp on what pre existing threads are doing. If the body file is created first, before the header file, then a non existent body file means "this entry has been invalidated, try the request again".
There is an assumption that <timestamp> is fine grained enough to be unique. You're right, this is a tricky one, but there is a solution out there. Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
