Nós vimos até agora que os bancos de dados, sejam eles relacionais, NoSQL ou NewSQL, precisam se posicionar sobre os temas de bloqueio, acesso e modificação de dados e também a concorrência ou simultaneidade de operações que estão acontecendo. Agora vamos nos aprofundar no bloqueio otimista. Vamos lá! O bloqueio otimista, como o nome já nos sugere, é um bloqueio que parte da premissa em que conflitos não acontecem com frequência, ou seja, são raros. não acontecem com frequência, ou seja, são raros. A maior parte das transações é concluída sem nenhum tipo de interferência ou gestão do banco de dados sobre esta resolução de conflitos. Então, não vai acontecer o bloqueio de dados antes das operações de leitura e escrita, porém, ao término da transação é verificado se aconteceu alguma alteração. Se alguma outra alteração tiver modificado aqueles dados do escopo dessa transação vigente, a transação vai ser abortada e devemos sentar novamente. Então, aqui nós temos, neste bloqueio otimista, um cenário que vai favorecer operações de leitura mais frequentes do que operações de escrita. E onde também um bloqueio de dados constante causaria uma degradação de desempenho. Vamos aos passos de um bloqueio otimista. Então, primeiramente, vai acontecer a leitura inicial dos dados necessários à transação que está sendo executada neste instante. Logo em seguida, existe uma marcação ou cópia destes dados originais para finalmente chegar no ponto de execução da transação. Aqui nós vamos ter as operações de modificação dos dados acontecendo, partindo de um isolamento, como se não acontecesse nenhuma concorrência, ninguém mais está mexendo nesta mesma massa de dados. Não existe nenhum bloqueio. Logo em seguida, vai acontecer a verificação dos possíveis conflitos, para entender se outros processos modificaram esses dados originalmente. E se os dados foram alterados por outra transação desde o momento em que foram lidos, pela transação atual que está em execução, então isso já nos caracteriza como um conflito e isso precisa ser resolvido. Então nós vamos chegar no último passo, que é a resolução dos conflitos, aqui no bloqueio otimista, e essa resolução geralmente está associada com o cancelamento da transação e ela precisa ser executada novamente. Mais para frente nós vamos ver que outras estratégias de resolução de conflitos podem ser aplicadas para garantir a consistência dos dados. Porém, em linhas gerais, aqui no bloqueio otimista, se alguma coisa mudou ao longo da execução da transação, vai ser cancelada a transação atual e essa transação precisa ser executada novamente. Vantagens que nós encontramos no bloqueio otimista. Então, o risco do deadlock, que é o impasse, fica mitigado. Melhor desempenho e escalabilidade em sistemas com muitas transações concorrentes, porque o esforço de gestão do banco de dados é relativamente menor comparado com o bloqueio pessimista, desvantagens, as aplicações precisam detectar e principalmente atuar na resolução de conflitos que estão acontecendo. Então, principalmente, essa retentativa de execução em caso de falha é algo que precisa ser feito na aplicação. Potencialmente, também, vai aumentar a latência e complexidade das transações que estão executando e um risco também aqui de redução de consistência e confiabilidade dos dados.