O bloqueio otimista é uma estratégia em que você lê um registro, anota um número de versão (outros métodos para fazer isso envolvem datas, carimbos de data/hora ou somas de verificação/hashes) e verifica se a versão não foi alterada antes de gravar o registro de volta. Quando você grava o registro de volta, filtra a atualização na versão para garantir que ela seja atômica. (ou seja, não foi atualizado entre quando você verifica a versão e grava o registro no disco) e atualiza a versão em um hit.

Se o registro estiver sujo (ou seja, versão diferente da sua), você aborta a transação e o usuário pode reiniciá-la.

Essa estratégia é mais aplicável a sistemas de alto volume e arquiteturas de três camadas em que você não necessariamente mantém uma conexão com o banco de dados para sua sessão. Nessa situação, o cliente não pode realmente manter bloqueios de banco de dados, pois as conexões são obtidas de um pool e você pode não estar usando a mesma conexão de um acesso para o próximo.

Bloqueio Pessimista é quando você bloqueia o registro para seu uso exclusivo até terminar com ele. Ele tem integridade muito melhor do que o bloqueio otimista, mas exige que você tenha cuidado com o design do aplicativo para evitar Deadlocks. Para usar o bloqueio pessimista, você precisa de uma conexão direta com o banco de dados (como normalmente seria o caso em um aplicativo de servidor cliente de duas camadas) ou um ID de transação disponível externamente que possa ser usado independentemente da conexão.

Neste último caso, você abre a transação com o TxID e, em seguida, reconecta usando esse ID. O DBMS mantém os bloqueios e permite que você recupere a sessão por meio do TxID. É assim que as transações distribuídas usando protocolos de confirmação de duas fases (como transações XA ou COM+) funcionam.