Skip to content
This repository has been archived by the owner on Apr 27, 2024. It is now read-only.

Verificar se existe concorrência ou racing conditions entre a API e o Worker svc #23

Closed
gabriellima09 opened this issue Oct 21, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@gabriellima09
Copy link
Collaborator

verificar se quando os dois estão operando em paralelo e alterando status do pedido, temos problemas/exceções de banco

@gabriellima09
Copy link
Collaborator Author

iremos fechar essa issue mediante a discussão dos seguintes pontos abaixo:

  • a arquitetura da aplicação é hexagonal, o que implicaria na componentização da aplicação .. e se usarmos o AddHostedService(), estaríamos acoplando a execução do worker na API, que hoje, um é independente do outro .. basicamente pro worker funcionar ele dependeria da API subir e não parar, senão ele seria afetado
  • no quesito Scoped x Singleton, o Scoped vai "limpar" as coisas assim que a requisição acabar, o que é perfeito pra API, mas no caso do hosted service não existe uma request .. existe uma chamada de service dentro de um while(true) que a cada ~25s vamos estar fazendo uma consulta, mas no pior cenário (sem pedidos) vamos ter a execução de uma query a cada 5s abrindo e fechando conexão com o banco (se fosse scoped) .. pra esse cenário de 5s, sendo singleton, podemos reaproveitar a conexão ainda que no mais demorado ainda daria pra relevar já que o svc vai ficar rodando "eternamente" .. como não temos múltiplas instâncias não precisaríamos nos preocupar com polling das conexões ou algo do gênero por hora
  • a concorrência entre serviços se dava pelo fato de que temos 2 apps usando a mesma base de dados, tanto que no startup tivemos que lockar a thread que consulta/cria o banco e aplica as migrations pq tava dando concorrência na execução (a API e o Worker estavam tentando criar a base e aplicar as migrations em paralelo, o que dava exception), acreditamos que está resolvido já que agr temos o startup thread-safe e optamos por isolar a fila de pedidos em uma view (que não é o melhor jeito, mas deve resolver até termos mensageria)
  • já nas racing conditions seriam os dois serviços (ou threads) tentando alterar o mesmo pedido ao mesmo tempo, podendo até ser via troca de status .. mas analisando nosso fluxo da vida do pedido, não teríamos esse cenário de dois services tentando alterar o pedido no banco ao mesmo tempo .. talvez se tivermos isso no futuro podemos ver algo como transações ou até um lock otimista pra garantir consistência ... dependendo essa issue até morreria por hora e abriríamos outra caso surgisse

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Development

No branches or pull requests

1 participant