Great benefits of simple observation that you can combine multiple transactions into one and still get the same result. But does it mean that your isolation level is serializable?

From my understanding of ayende's blog, if explain in different way, it would be following.

Network side: DTO (Data Transfer Object). This is achieved through session.SaveChanges(). Which RavenDB client will combine non conflict changes to database in one HTTP call. Similar to MSFT's batch request.

Local IO: This is similar to SSE (Server Sent Event). Where RavenDB need queue to process changes to disc in sequencial manner. The request from network is concurrent. The goal is write to disk right away if no queue, then buffer and batch process if there is queue.

To achieve single write from concurrent source, we could use ActionBlock and setup max concurrency to 1 and with maximum buffer. Such approach unable to batch. We could of course use batch block from DataFlow library, but such batch operation require fixed size. So it is not exactly fit.

Without .Net Core 3 we could use ConcurrentQueue plus TaskCompletionSource.

class ProcessQueue {
    private readonly ConcurrentQueue<TransactionInstruction> _queue;
    private TaskCompletionSource<object> _nextArrival = new TaskCompletionSource<object>();
    private readonly _lock;

    ProcessQueue() {
        Execute();
    }

    public Enqueue(TransactionInstruction item) {
        _queue.Enqueue(item);
        var next = new TaskCompletionSource<object>();
        TaskCompletionSource<object> old = Interlocked.Exchange(ref _nextArrival, next);
        old.TrySetResult(null);
    }

    private Execute() {
        while(true) {
            ProcessuntilEmpty();

            await _nextArrival.Task;
        }
    }

    private ProcessUntilEmpty()
    {
        while(true) {
            TransactionInstruction[] batch = GetNextBatch();
            WriteToDisc(batch);

            if(noMoreInQueue) {
                return;
            }
        }
    }

    private GetNextBatch() {
        // get 10 items from _queue or if there is no more in queue or there is conflict between tasks.
    }
}

With latest .Net. you can use ChannelReader, it can achieve similar outcome.

The question about isolation level begs another one - is there any interference possible between separate transactions caused by the fact that they have been merged? For example, some dirty reads - seeing changes made by another transaction in a batch, which shouldn't be visible because that transaction hasn't committed yet? If reads and updates are in separate transactions then probably not an issue, but is it even possible?

..or maybe it doesn matter at all because order of transactions in a batch is not a part of the contract, and in the end either all will be committed or nothing - so no dirty reads, just reading of data that would be there anyway if transactions were executed one by one.

Jason,

If you're not familiar already, you may want to check out CosmosDB's Bulk support (source here), which implements a similar batching system with the Timer Wheel algorithm. (It also uses task continuations so that even though requests are posted as a batch, each request can be awaited individually - a trick I haven't seen elsewhere yet.)

Only see Avi's note today, don't think he will notice my reply.

I also think it sounds cool but it is not ideal design. It is something for in-experienced developer but less flexible and low performance. I know where they came from, since I have fixed people's code in EF, where an operation could take hour to process in SQL, where if use bulk action of EF, it can easily shrink down to few min. Without change the whole architecture. Average developer have no idea of bulk concept and they don't care. Probably because the environment I am at is the case, but for Microsoft, majority of their user base is like that. So make it fool approve rather than performance is the way to go. Even with such implementation, I doubt many will use that flag.

The reason I like RavenDB's batch approach or Graph API's batch approach, is because it is explicit. You setup work and you explicitly tell it to execute. In Zen of Python, quote.

Explicit is better than implicit.

With explicit, you can control when to execute and how to execute. On the other hand, RavenDB and Graph API's explicit approach also means performance. You set up tasks, and you call execute, no time need to be wait. No performance penalty. The execution is in ns. Of course I never measured, but one thing to guarantee, when you call SaveChanges in RavenDB client, or SendBulk in GraphApi, it execute immediately.

When create and modify items, in most of cases, you want it to be as quick as possible. Especially for read. Once you read the data from database and you want to modify, you want to race with other actor. The longer it waits, higher chance optimistic concurrency will throw. That is why, before call SaveChanges it is good to Refresh the object and verify again if there was lengthy operation between read and update.

As for Local disk operation, such time wheel approach is also not good. It could easily create bottle neck, as there is timer involved. The approach RavenDB take, or the channel reader & writer take won't have timer involved. If there is no items in queue, it will execute immediately. Of course it need additional allocation before we can make it await individually, but we don't want to await individually. As long as we can ensure it is in the queue, and the queue can be persist during unexpected shutdown, that's good enough. For such scheduled operation, it can still be awaited using state approach. Similar to RavenDB's query patch operation.

Time wheel algorithm is more closed to or is nagle algorithm, which is the thing many people hate and want to be disabled. It has good throughput but high latency. That has been described in the MSFT article you have posted. Where they clearly state, only use if you don't care about latency.

Thanks Oren.

It is a bit of hard to navigate in the code through GitHub website. From just looking at time wheel class, it feels like similar to nagle algorithm which throttle any request to see if there are follow ups.

RavenDB client internally same as Microsoft Graph API. They all have RESTful API for batch commands. RavenDB version.

I have thought about it after my own post. Time wheel algorithm's benefit seems very limited. It sounds like only flip a flag, but without use Task.WaitAll, if you await individually, they are still result in separate request. Since if you await individually, it won't execute next line until existing has completed. Thus, each request can be await individually, is a false claim unless developer use sync to add task, then await individually.

Example 1:

await container.CreateItemAsync(itemToInsert, new PartitionKey(itemToInsert.MyPk));
await container.CreateItemAsync(itemToInsert, new PartitionKey(itemToInsert.MyPk));
// that will result with two requests, not one. Since it will await until first one is finished before give next instruction.

Example 2:

Task task1 =  container.CreateItemAsync(itemToInsert, new PartitionKey(itemToInsert.MyPk));
Task task2 =  container.CreateItemAsync(itemToInsert, new PartitionKey(itemToInsert.MyPk));
await task1;
await task2
// most likely they will be combined  into one batch request. 

With similar RESTful API in the background, Microsoft Graph API library expose it directly. Where you have to await on the HTTP call, then get result from individual request through an Array of command. Which is hard to work with.

RavenDB client introduced many different approaches all powered by same RESTful API I believe. The Savechanges is only one of them. There are lazy operations, defer on patch operations, batch command through session.Advanced.RequestExecutor. Even though time wheel is a unique way to achieve similar outcome with latency, but personally I prefer performance and more explicit approach. Less random. If same code execute 1,000 times, the way of executing should always be same. The number of batch request sent to database should always be same.

For time wheel it is a bit random. I better give an example.

// Cosmos DB
Task task1 = container.CreateItemAsync(itemToInsert, new PartitionKey(itemToInsert.MyPk));

await InternalOperationAsync();

task task2 = container.CreateItemAsync(itemToInsert, new PartitionKey(itemToInsert.MyPk));

// It could result two request or one, depends on the await in the middle.
await Task.WhenAll(task1, task2);

// RavenDB example.
await session.StoreAsync(item1);
await InternalOperationAsync();
await session.StoreAsync(item2);

// always one request against database.
await session.SaveChangesAsync();

As for local disk operation, as long as each time period not limit on amount of task can be executed, all throw into an queue, then there shouldn't be much problem as bottle neck, it only means it will be delayed when there is no items in the queue.