Vinicius Quinafelex Alves

Linguagens orientadas a objetos costumam gerenciar registros de banco de dados através classes e objetos que representam a estrutura do banco. Eric Evans, em seu livro de domain-driven design, classifica estas classes como classes de Entidade.

Assim, regras de negócios podem usar esses objetos para fazer checagens e alterar seus valores, e posteriormente os novos dados podem ser persistidos no banco de dados de uma forma consistente.

Cenários com concorrência

Em ambientes com execuções em paralelismo, como web APIs, um única entidade pode ser acessada por múltiplas threads ao mesmo tempo, carregando objetos distintos, sendo que cada thread pode alterar os valores do seu objeto de acordo com a regra de negócio correspondente.

Porém, tentar persistir todos os objetos dessa entidade em um único registro do banco de dados pode gerar conflitos e dados podem ser sobreescritos, quebrando a consistência.

Exemplo de inconsistência

O código abaixo demonstra um cenário aonde diversas threads tentam incrementar o valor de uma única entidade 10.000 vezes em paralelo.

var userId = 1;

// Setup
var userRepository = new UserRepository();
var parallelOptions = new ParallelOptions() 
{ 
    MaxDegreeOfParallelism = 10 
};

// Execution
Parallel.For(0, 10_000, parallelOptions, (attempt) => 
{
    var user = userRepository.GetByID(userId);
    user!.IncrementalValue++;

    userRepository.Update(user);
});

// UserRepository Class
public void Update(User user)
{
    using(var conn = new MySqlConnection(ConnectionString))
    using(var command = conn.CreateCommand())
    {
        command.CommandText = "UPDATE User SET IncrementalValue = @IncrementalValue WHERE ID = @ID;";
        command.Parameters.AddWithValue("@ID", user.ID);
        command.Parameters.AddWithValue("@IncrementalValue", user.IncrementalValue);

        conn.Open();
        command.ExecuteNonQuery();
    }
}

Como cada execução incrementa o valor em 1, é esperado que depois de 10.000 execuções o IncrementalValue esteja com 10.000. Mas como a função UPDATE apenas sobreescreve os dados cegamente em um cenário de alta concorrência, na prática o valor final será muito menor, em alguns testes chegando a valores menores que 2.000.

Em um ambiente de produção, isso indica que potencialmente 80% das operações gerem resultados inconsistentes.

Mantendo a consistência

Este tipo de cenário precisa implementar algum tipo de controle de concorrência, de forma que uma thread não sobreescreva os resultados das demais

Uma forma popular de evitar concorrências é através do uso de locks. Assim uma thread não pode utilizar um recurso, ou acessar um trecho de código, enquanto outro processo mantiver um lock nele.

Porém, locks oferecem algumas desvantagens, como a necessidade de gestão de deadlocks, granularidade eficiente para evitar excesso de contenção e tolerância à falhas em cenários com sistemas distribuídos.

Além do lock, existem diversas outras formas e implementações de controle de concorrência, aonde cada solução é mais apropriada para diferentes tipos de cenários.

Commitment ordering

Commitment ordering é um método de controle de concorrência otimista sem uso de locks.

Neste método, um objeto só pode ser persistido se o banco de dados ainda estiver com os mesmos dados que foram utilizados para criar o objeto. Uma forma de realizar essa verificação é através do versionamento do registro, em que qualquer atualização do registro também deve alterar a versão dele.

Quando ocorre uma falha por divergência de versão, o tratamento pode ser feito baseado no caso de uso. Por exemplo, se a função é disparada por usuários, seria possível emitir um erro indicando que os dados originais foram alterados e recarregar os dados exibidos. Dessa forma, o usuário pode decidir se ainda faz sentido executar a função em cima do novo conjunto de dados.

Esta é uma solução de controle de concorrência relativamente simples para ser implementado em sistemas distribuidos ou containerizados, aonde o uso de locks externos pode ser complexo.

Implementação

Alguns bancos de dados e bibliotecas já oferecem funcionalidades de commit ordering. Por exemplo, o SQL Server possui o tipo de coluna rowversion e a biblioteca de ORM Entity Framework possui concurrency tokens. Mesmo assim, a lógica não é difícil de implementar na maioria dos bancos SQL.

O exemplo abaixo demonstra uma implementação simplificada, adotando a estratégia de, quando houver um conflito de versão, deve reiniciar o processo do começo, recarregando todos os objetos com os dados mais recentes.

var userId = 1;

// Setup
var userRepository = new UserRepository();
var parallelOptions = new ParallelOptions() 
{ 
    MaxDegreeOfParallelism = 10 
};

// Execution
Parallel.For(0, 10_000, parallelOptions, (attempt) => 
{
    var successful = false;

    do
    {
        var user = repo.GetByID(id);
        user!.IncrementalValue++;

        successful = repo.TryUpdateWithToken(user);
    } while(!successful);
});

// UserRepository Class
public bool TryUpdateWithToken(User user)
{
    var newVersion = Guid.NewGuid();

    using(var conn = new MySqlConnection(ConnectionString))
    using(var command = conn.CreateCommand())
    {
        command.CommandText = "UPDATE User SET total = @total, version = @newVersion WHERE id = @id AND version = @oldVersion;";
        command.Parameters.AddWithValue("@id", user.ID);
        command.Parameters.AddWithValue("@total", user.IncrementalValue);
        command.Parameters.AddWithValue("@oldVersion", user.Version);
        command.Parameters.AddWithValue("@newVersion", newVersion);

        conn.Open();
        var changedRowCount = command.ExecuteNonQuery();
        var hasChanged = changedRowCount > 0;

        if(hasChanged)
            user.Version = newVersion;

        return hasChanged;
    }
}

Após a execução, o IncrementalValue corretamente termina com o valor 10.000. Porém, esta estratégia de tratamento é mais adequada para situações aonde apenas uma pequena quantidade de threads tenta atualizar a mesma entidade. Caso contrário, as repetidas tentativas de atualização podem ser computacionalmente caras.

Para esta demonstração, em média cada iteração passou por 9 divergências de versão antes de conseguir atualizar o registro com sucesso, o que totaliza cerca de 90.000 tentativas de execução de UPDATE.