sbtourist/Journal.IO — Issue #8: Awaiting completion of asynchronous writes
Author: chrisvest
Created: 2012-02-14 11:20:27+00:00
State: open

### Use case

Consider some server process that takes any number of concurrent requests, and concurrently writes stuff to a Journal. The rules of this program is that the requests cannot be considered complete until their data is synced to disk, yet the system is busy enough that using fully synchronous writes will have an undesirable negative performance impact.

We want to make asynchronous writes, and delay our acknowledgement of the requests until the writes are synced. This would give the program the throughput of asynchronous writes, with the durability guarantees of fully synchronous writes. The only drawback (as far as I can tell) is the greater number of in-flight writes that can be lost if the program were to crash.

### Implementation considerations

I don't know if this is already possible with the current API and/or implementation.

If it is not possible, then I have an idea for an API change. Instead of letting the Journal.write method take a boolean, representing whether the write will be asynchronous or not (or is it synchronous? easy to forget), then split the method in two: one writeSync and one writeAsync. The writeSync method can return a Location as always, while the writeAsync can return something that has a Location (because Locations are always immediately available, even on asynchronous writes) and which knows whether the write has been synced to disk or not. It would also have await methods, so that one can await the disk sync.

Alternatively, the Location can be extended with these same methods, so that a Location knows whether or not it has been synced to disk and if not, can be awaited upon.