Condição de corrida pode causar perda de dados (lost updates)

[gustavofonseca]

O diagrama abaixo ilustra uma situação, possível de ocorrer com a implementação atual, em que a modificação feita por Usuário B é perdida:

O problema se manifesta quando dois ou mais atores modificam um mesmo registro de forma que modificações são feitas a partir do registro num estado desatualizado.

No momento presente (https://github.com/scieloorg/kernel/releases/tag/v0.1rc2), todos os tipos de entidade do Kernel estão vulneráveis ao bug.

[jamilatta]

@gustavofonseca

Muito bem observado!

[gustavofonseca]

A proposta de solução faz uso de um mecanismo chamado Fencing Token, apresentado no livro Designing Data-Intensive Applications, que funciona da seguinte maneira: todas as vezes em que registros de journal, bundle ou document forem consultados, será retornado como parte dos dados um fencing token, que identifica o estado daquele registro naquele momento e que deve ser enviado de volta ao servidor junto com qualquer modificação, de maneira que o servidor saiba o estado que originou aquele novo estado.

A exemplo do CouchDB, que utiliza fencing tokens como mecanismo de controle de concorrência, esta proposta prevê representar o token pelo identificador _rev, ao qual será atribuído um valor pseudo-aleatório. Não é necessário que o valor seja produzido de maneira sofisticada, como um UUID, mas um simples número inteiro (int32) pode fazer o trabalho, e é esta a sugestão.

O método adapters.BaseStore._pre_write poderá ser modificado para que passe a retornar também o valor atual de _rev, além de defini-lo com um novo valor, conforme o exemplo abaixo:

    def _pre_write(self, data) -> dict:
        """Tratamento anterior ao armazenamento do dado no MongoDB."""
        _manifest = data.manifest
        if not _manifest.get("_id"):
            _manifest["_id"] = data.id()
        current_rev = _manifest.get("_rev")
        _manifest["_rev"] = random.randint(1, 999999999)  # não retorna zero para evitar bugs em avaliação booleana
        return current_rev, _manifest["_id"], _manifest

O método adapters.BaseStore.update terá que ser modificado para que o token corrente seja utilizado na busca pelo registro a ser modificado, conforme o exemplo abaixo:

    def update(self, data) -> None:
        _rev, _id, _manifest = self._pre_write(data)
        filters = {"_id": _id}
        if _rev is not None:
            filters["_rev"] = _rev
        else:
            filters["_rev"] = {"$exists": False}
        result = self._collection.replace_one(
            filters, _manifest, **self._txn_session_arg()
        )
        if result.matched_count == 0:
            raise exceptions.DoesNotExist(
                "cannot update data with id " '"%s": data does not exist' % data.id()
            )

A implementação desta proposta não demandaria a migração dos dados para a inclusão do campo _rev em todos os registros. Acredito que o maior impacto de mudanças seria na API RESTful, onde todas as operações de escrita teriam seus schemas modificados para incluir o campo.

Para discussão

1. Faz sentido aplicarmos este mecanismo também nos endpoints de documents ou apenas em journals e bundles? Se fizer sentido, qual o local mais indicado para expor o valor de _rev?