+972 52-548-6969
The worker pattern
In RavenDB 4.0, we are writing a lot of code that need to do something, then react to something, then do something, etc.
For example, an index need to index documents until it runs out, then it wait for more documents, and when they arrive, it index them, and then wait, etc.
Here are two such examples (note that the code is written just to demonstrate a point):
In the first example, we see how we handle indexing. The outer loop runs as long as we the database runs, and then we index until we run out of stuff to do. When we run out, we’ll wait. During that time, the thread is paused, and unless a new document comes for the collections that this index covers, there is nothing that needs to be done.
In the other case, we are actually handling a web socket connection, so there are some differences, but for the most part, this is pretty much the same. We use an async event, and we need to keep the connection alive, so if we have nothing to do, we’ll wake up every 5 seconds and just write a new line to the socket, keeping it alive.
Nitpicker corner: this isn’t new, and it is about the simplest and most obvious concurrency strategy you can have.
But because it is the simplest, it also have some major advantages. The code does very little actual concurrency. We can reason about the code quite easily. We keep having to dumb down our code to similar patterns, because this is much easier to maintain over the long run.
Comments
If I understand correctly, when you want to shutdown the database you call CancellationTokenSource.Cancel(), this causes wait.Wait(database.ShutdownCancellationToken) to throw OperationCancelledException so the indexing process stops.
Jesus, Effectively, yes.
Comment preview