Para o bloqueio otimista, você precisa definir alguns meios para verificar se uma linha foi alterada desde a última vez. Por exemplo, vamos apenas adicionar outro identificador:
alter table regions_indexes add version_id integer default 1 not null;
Agora a aplicação lê alguma linha, mostra os dados para o usuário e espera até que o botão seja clicado. Devemos lembrar o valor de
version_id obtemos. Após clicar no botão, você executa todos os cálculos necessários. Quando estiver pronto para atualizar a linha, bloqueie a linha e verifique se
version_id Não mudou. Se não tiver, incremente version_id e cometer. Se tiver, azar --- você precisa dizer ao usuário para repetir a operação porque alguém o ultrapassou. Pode ser assim (em pseudocódigo):
-- remember version_id
select *
from regions_indexes
where id = ... and resource_type = ...;
-- wait for user click
-- you can wait for a long time, because no lock is yet acquired
...
update regions_indexes
set current_resource = current_resource - ..., version_id = version_id + 1
where id = ... and resource_type = ...
returning version_id;
if new_version_id = old_version_id + 1 then
-- success, commit
else
-- fail, rollback
end if;
Mas o bloqueio otimista não funciona bem em situações de alta simultaneidade. Quando os conflitos não são raros, você terá que reiniciar as transações com frequência.
