Re: Presenting BoostServerTech chat

From: Matt Pulver (mpulver_at_[hidden])
Date: 2023-09-07 14:21:08

On Thu, Sep 7, 2023 at 7:31 AM Ruben Perez <rubenperez038_at_[hidden]> wrote:

> > A more advanced app, and what I would like to see personally, is an
> example and architectural discussion on design patterns involving how best
> to handle server requests that require more time/resources that may not be
> appropriate for a single-threaded server (e.g. a database server.) From a
> high-level perspective, my current thinking on this is:
>
> I guess you mean any protocol that does not have an async library, or a
> resource-intensive task such as image processing? If there is a specific
> task or protocol you'd like to see, please do mention it.
>

The example I have in mind is an actual database server (not client) which
uses Boost.Asio to handle SELECT, UPDATE, CREATE TABLE sql statements, etc.

The challenges posed by a database server are quite general and will apply
to many applications, and I would guess that any developer considering
using Boost.Asio for handling asynchronous I/O operations will have
questions along the lines of:

   - How should I handle longer requests that are delegated to a thread
   pool, especially with respect to resource contention? E.g. An UPDATE query
   to table A should lock table A so that asynchronous SELECT queries on A
   don't read inconsistent data.

A few ideas that come to mind are:

   - Use traditional mutexes and lock guards
   <https://en.cppreference.com/w/cpp/thread/lock_guard> for each table.
   - Use unique locks <https://en.cppreference.com/w/cpp/thread/unique_lock>
   on writes, and shared locks
   <https://en.cppreference.com/w/cpp/thread/shared_lock> for reads.
   - Use a locking manager to avoid deadlocks (if scoped lock
   <https://en.cppreference.com/w/cpp/thread/scoped_lock> isn't sufficient.)
   - A completely different paradigm: Multiversion Concurrency Control
   <https://www.postgresql.org/docs/current/mvcc-intro.html> as PostgreSQL
   uses, in which changes are done to a separate version of the data. (This is
   quite a general concept and doesn't just apply to databases.) When
   completed, the version upgrade can be done in the main Boost.Asio thread
   and thus avoid locking (with caveats).

Are there more modern/sophisticated techniques to deal with these issues?
Or if they are outside the scope of Boost.Asio, it is still worth
mentioning them so that we know to deal with them at the right level in the
architecture.

These are the types of considerations/discussions I am interested in.