O controle de concorrência otimista é um paradigma de gestão de acesso a dados que se aplica em cenários onde a probabilidade de conflitos simultâneos entre transações é relativamente baixa. Em vez de impor bloqueios preventivos nos dados, a validação de conflitos é postergada para o momento da submissão da transação. A integridade e consistência dos dados são asseguradas, tipicamente, através do uso de números de versão ou de carimbos de data/hora (timestamps).

Este método permite uma gestão de concorrência eficiente, caracterizada por um design sem bloqueios e um alto rendimento, sendo particularmente vantajoso em ambientes de alta concorrência e baixa colisão, como os encontrados em aplicações web modernas. Um timestamp serve como um identificador numérico ou de string que registra o momento exato em que um evento ocorreu. Sua função primordial é fornecer uma marca temporal única para um ponto específico no tempo. Essencialmente, é a 'coordenada temporal' no mundo digital, padronizando o registro de eventos para assegurar consistência entre sistemas e fusos horários, exigindo atenção à precisão, zona horária e formato de armazenamento.

Fluxo Central do Controle de Concorrência Otimista

O processo de aplicação do bloqueio otimista segue uma sequência de passos bem definida:

Leitura dos Dados

Inicia-se pela recuperação dos dados alvo juntamente com seu identificador de versão atual.

Modificação dos Dados

A lógica de negócio processa as informações lidas, gerando um novo conjunto de dados a ser persistido.

Confirmação da Atualização

No momento de gravar as modificações, a instrução SQL de atualização verifica se o número de versão dos dados no banco de dados ainda corrresponde ao número de versão lido inicialmente. Se corresponder, os dados são atualizados e a versão incrementada.

UPDATE nome_da_tabela
SET
   coluna_de_dados = novo_valor_de_dados,
   versao = versao + 1
WHERE
   id_registro = id_do_alvo
   AND versao = versao_inicial; -- Verifica se a versão não foi alterada por outra transação

Verificação do Resultado

Se a versão no banco de dados corresponder à versão inicial, a atualização é bem-sucedida. Caso contrário, se a versão já tiver sido modificada por outra transação, a operação falha, indicando um conflito de concorrência.

Estratégias de Resolução de Conflitos

Quando um conflito de versão é detectado, diversas estratégias podem ser aplicadas para resolver a situação, dependendo da natureza da operação e dos requisitos de negócio.

Reexecução Automática

Este cenário é apropriado quando a chance de conflitos é baixa e a lógica de negócio permite reexecuções. Uma abordagem comum é interceptar a exceção de conflito de bloqueio otimista, recarregar a versão mais recente dos dados do banco de dados, aplicar novamente a lógica de negócio sobre os dados atualizados para recalcular os valores a serem persistidos e, então, tentar a atualização novamente. É crucial limitar o número de tentativas para prevenir o esgotamento de recursos.

import org.springframework.transaction.annotation.Transactional;
import org.springframework.orm.ObjectOptimisticLockingFailureException; // Exceção específica do Spring

// Simulação de uma entidade e seu repositório para o exemplo
class EntidadeSimulada {
   private Long id;
   private int versao;
   private double valor; // Exemplo de atributo que será modificado

   public EntidadeSimulada(Long id, int versao, double valor) {
       this.id = id;
       this.versao = versao;
       this.valor = valor;
   }

   public Long getId() { return id; }
   public void setId(Long id) { this.id = id; }
   public int getVersao() { return versao; }
   public void setVersao(int versao) { this.versao = versao; }
   public double getValor() { return valor; }
   public void setValor(double valor) { this.valor = valor; }

   // Método para aplicar mudanças, simulando a lógica de negócio
   public void aplicarDelta(double delta) {
       this.valor += delta; // Exemplo: somar um delta ao valor
   }
}

// Simulação de um repositório genérico
interface RepositorioGenerico {
   EntidadeSimulada buscarPorId(Long id);
   void salvar(EntidadeSimulada entidade); // O ORM/Framework cuidaria do incremento da versão
}

// Implementação do serviço que usa o bloqueio otimista com reexecução
@Transactional
public class ServicoAtualizacaoDados {

   private final RepositorioGenerico repositorio;

   public ServicoAtualizacaoDados(RepositorioGenerico repositorio) {
       this.repositorio = repositorio;
   }

   /**
    * Tenta atualizar uma entidade com bloqueio otimista e reexecução automática em caso de conflito.
    * @param id O ID da entidade a ser atualizada.
    * @param delta O valor a ser aplicado (ex: somado) ao atributo 'valor' da entidade.
    * @throws RuntimeException se a atualização falhar após múltiplas tentativas.
    */
   public void processarAtualizacaoOtimista(Long id, double delta) {
       final int MAX_TENTATIVAS = 3;
       for (int tentativa = 0; tentativa < MAX_TENTATIVAS; tentativa++) {
           try {
               // 1. Reconsulta a entidade mais recente
               EntidadeSimulada entidadeAtualizada = repositorio.buscarPorId(id);
               if (entidadeAtualizada == null) {
                   throw new RuntimeException("Entidade com ID " + id + " não encontrada.");
               }

               // 2. Aplica a lógica de negócio sobre os dados mais recentes
               entidadeAtualizada.aplicarDelta(delta);

               // 3. Tenta salvar a entidade atualizada (incrementando a versão automaticamente pelo ORM)
               repositorio.salvar(entidadeAtualizada);
               return; // Sucesso: a atualização foi concluída
           } catch (ObjectOptimisticLockingFailureException e) {
               // 4. Captura o conflito de bloqueio otimista e prepara para reexecutar
               if (tentativa == MAX_TENTATIVAS - 1) {
                   throw new RuntimeException("Falha ao atualizar dados após " + MAX_TENTATIVAS + " tentativas.");
               }
               // Opcional: atrasar a próxima tentativa (backoff exponencial)
               try {
                   Thread.sleep(50L * (tentativa + 1)); // Exemplo de backoff simples
               } catch (InterruptedException ie) {
                   Thread.currentThread().interrupt();
                   throw new RuntimeException("Reexecução interrompida.", ie);
               }
           }
       }
   }
}

Intervenção Manual do Usuário

Quando um conflito resulta em um estado de negócio inconsistente que exige uma decisão humana, a estratégia é notificar o usuário. Isso geralmente envolve apresentar uma mensagem indicando que os dados foram alterados por outra parte, exibindo as diferenças entre os dados originais, a versão do usuário e a versão mais recente do servidor, e permitindo que o usuário escolha entre sobrescrever, mesclar ou abandonar suas próprias alterações.

// Após o envio de uma requisição de atualização, o backend pode retornar um erro de conflito
function lidarComRespostaDeAtualizacao(resposta) {
   if (resposta.status === 409 && resposta.erro.codigo === 'CONFLITO_BLOQUEIO_OTIMISTA') {
       // Exibir um diálogo ao usuário, comparando as diferentes versões dos dados
       exibirDialogoConflito(
           resposta.erro.dadosDoUsuario,   // Dados que o usuário tentou enviar
           resposta.erro.dadosAtuaisServidor // Dados atualmente persistidos no servidor
       );
   } else if (resposta.status === 200) {
       console.log("Atualização realizada com sucesso!");
   } else {
       console.error("Ocorreu um erro inesperado:", resposta.erro);
   }
}

function exibirDialogoConflito(dadosUsuario, dadosServidor) {
   // Implementação da interface do usuário para mostrar ao usuário as diferenças
   console.log("Conflito detectado!");
   console.log("Seus dados propostos:", dadosUsuario);
   console.log("Dados atuais no servidor:", dadosServidor);
   // Aqui, o usuário teria opções como "Sobrescrever", "Mesclar" ou "Cancelar"
}

Lógica de Fusão Baseada em Regras de Negócio

Em situações onde os conflitos podem ser resolvidos de forma autônoma e determinística pelas regras de negócio — como no decremento de contadores ou ajuste de estoque — pode-se aplicar uma lógica de fusão que não exige intervenção do usuário. Nesses casos, a operação é reavaliada com base no estado atual dos dados, em vez de depender da versão inicial, e a atualização é executada diretamente.

-- Esta abordagem não necessita de um campo de versão para garantir a consistência
-- em operações como decremento, pois opera diretamente sobre o valor atual
-- e uma condição (e.g., estoque > 0)
UPDATE produtos
SET
   estoque = estoque - 1
WHERE
   id_produto = 1001 AND estoque > 0;

Considerações Importantes

Balanceamento de Tentativas de Reexecução

Um número excessivo de tentativas de reexecução pode degradar o desempenho do sistema, enquanto poucas tentativas podem resultar em uma experiência insatisfatória para o usuário. Recomenda-se um equilíbrio, geralmente entre 3 e 5 tentativas, idealmente implementadas com uma estratégia de backoff exponencial para espaçar as tentativas e reduzir a carga no banco de dados.

Prevenção do Problema ABA

Este problema ocorre quando um valor de dados muda de A para B e depois retorna para A. Se o mecanismo de versão permitir que os números de versão se repitam (por exemplo, em um ciclo), uma transação pode inadvertidamente considerar que os dados não foram alterados. Para mitigar isso, deve-se empregar números de versão irreversíveis, como timestamps com alta granularidade ou inteiros que incrementam monotonicamente.

Escalabilidade em Sistemas Distribuídos

Em ambientes distribuídos de alta concorrência, o bloqueio otimista pode ser complementado com mecanismos de bloqueio distribuído para reduzir a probabilidade de colisões. Adicionalmente, é imperativo garantri que os números de versão sejam globalmente únicos e estritamente crescentes em todo o sistema distribuído para manter a consistência.

Controle de Limites Transacionais

É uma boa prática manter as transações o mais curtas possível. Transações de curta duração minimizam a 'janela de conflito', o período durante o qual os dados podem ser alterados por outra transação antes que a primeira seja confirmada. Transações longas, por outro lado, aumentam significativamente a chance de conflitos de concorrência.