Re: Presenting BoostServerTech chat

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2023-09-07 19:52:34

>
> 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.
>

I'd say this is out of scope of the BoostServerTech project, at least
as I had it in mind.
A database server is a quite specialized and complex piece of
software. I lack the
time and knowledge to write such an example. And I think it would
target a relatively
small part of our community.

That said, if you or any other person feels like doing it, you're
welcome to step in.

> 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 for each table.
> Use unique locks on writes, and shared locks for reads.
> Use a locking manager to avoid deadlocks (if scoped lock isn't sufficient.)
> A completely different paradigm: Multiversion Concurrency Control 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.

The issues you can find here are more related to concurrency
control and data structures than with asynchronous I/O. I'd say this is mostly
out of Asio's scope.

Regards,
Ruben.