SingleFileStore is not thread-safe for passivation

SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.

I've attached a test to reproduce the problem.
I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.

A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is.

I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.