Garantindo a Consistência de Dados com Locks Pessimistas e Locks Otimistas

Garantindo a Consistência de Dados com Locks Pessimistas e Locks Otimistas | Dias de Dev

Рет қаралды 2,127

Күн бұрын

Пікірлер: 53

@CaiqueUnico 8 ай бұрын

Ótimo vídeo. Gostaria que falasse mais sobre os níveis de isolamento de transações, como o "read uncommitted", "read committed", "snapshot", repeatble read" e "serializable".

@DiasDeDev 8 ай бұрын

Opa, ótima ideia! Vou preparar sim.

@jeanmascarenhas71 23 күн бұрын

Muito boa explicação

@v3ronez 2 ай бұрын

Que video bom, o vinicius é um monstro e explica muito bem!

@DiasDeDev 2 ай бұрын

Que bom que gostou, mano.

@cpp33 3 ай бұрын

acontece que uso de for update pode causar serios colaterais em alta concorrencia, como deadlocks. esses erros gerados no teste de carga nao deveriam acontecer, independente se obteve sucesso nos 10. Esses erros geram log, alem de inchar o arquivo de log, derruba desempenho, aumenta latencia. aconselharia outros 2 NOWAIT, onde irá falhar de imediato de nao puder ser obtido, em vez de esperar. SKIP LOCKED, simplesmente ignorará a linha bloqueada nao gerando fila. Se os 10 produtos ja foram trancados, o demais passam batidos. Nao geram fila, e com isso nao ira gerar erros. podendo ser tratado com uma mensagem amigavel ao usuario. usar FOR UPDATE tem mais maleficios que beneficios existe FOR SHARE tambem, ai deem uma pesquisada ai. alem de SERIALIZABLE, READ COMMITTED e seus outros 2 coirmaos, so nao usem UNCOMMITTED para dados criticos. quando for critico, ideal mesmo e o SERIALIZABLE. Mas vai de como é a criticidade.

@cpp33 3 ай бұрын

nao seria melhor usar serializable ? ou de repente ate mesmo um nivel abaixo para nao perder tanto na latencia ?

@vinelouzada 3 ай бұрын

Conteúdo enriquecedor, parabéns!

@DiasDeDev 3 ай бұрын

Valeu, xará!

@danielevangelista2302 8 ай бұрын

Nossa?! nunca pensaria nisso, essa canal mostra pontos chave bem pontuais. Parabéns!!!!!

@DiasDeDev 8 ай бұрын

Que bom que gostou! :-D

@Canemahue 8 ай бұрын

Real, o cara trás conteúdo diferenciado

@DiasDeDev 8 ай бұрын

Eu tento. :-D

@marcelgsantos 8 ай бұрын

Mais uma explicação com excelente didática. Além de explicar os conceitos muito bem você trouxe os trade-offs de cada solução. Além do mais, usar uma ferramenta para teste de carga torna o exemplo mais rico e embasado em qual solução adotar. 👏🏼 Ah, locks de banco de dados são normalmente traduzidos para o português como bloqueios. 😀

@DiasDeDev 8 ай бұрын

Opa, que honra, mestre! Fico muito feliz que tenha curtido.

@jhonatanjacinto 8 ай бұрын

Muito bom! Sempre gostei da abordagem pessimista (porque eu sempre acho que tudo vai dar errado... rs) ainda que haja custos de performance. Não conhecia a abordagem otimista. Muito legal saber como aplicar essa técnica. ✌️

@DiasDeDev 8 ай бұрын

Eu também tendo a tomá-la como padrão. :-D

@marcelomsmms 3 ай бұрын

Muito bom !!!!!

@DiasDeDev 3 ай бұрын

:-D Que bom que gostou!

@leofranca4126 8 ай бұрын

Esse assunto é muito interessante, é muito importante pensar em problemas de concorrência na aplicação, ótima explicação

@DiasDeDev 8 ай бұрын

Que bom que gostou! 😁

@wellingtondivino8263 8 ай бұрын

Primeiramente, quero dizer que seus conteúdos são tops e agregam valor demais para o nosso dia a dia como Dev. A dúvida que tenho é, a instrução SELET FOR UPDATE locka apenas a linha ou a tabela? se for a tabela, em um ambiente onde o cenário envolve termos mais de um pod em execução, o ideal seria ter um SELECT FOR UPDATE SKIP LOCKED?

@DiasDeDev 8 ай бұрын

A instrução trava os registros encontrados pra atualização. Ter mais de um pod não muda o cenário. Só vai ser impedido de acessar o registro quem, dentro de uma transação também, tentar bloquear o registro "for update". Select "normal" não fica bloqueado nesse cenário.

@wellingtondivino8263 8 ай бұрын

@@DiasDeDev obrigado pelo retorno!

@fabiosantana2517 8 ай бұрын

Já usei bastante

@DiasDeDev 8 ай бұрын

Boa!

@ikarolaborda726 8 ай бұрын

Muito bom. Por esses dias, tive um debate sobre esse tema, com essa explicação, agora consegui desafogar a mente da quantidade enorme de informações que obtive a respeito

@DiasDeDev 8 ай бұрын

Fico feliz que tenha sido útil. 😁

@zakrom3763 8 ай бұрын

@Dias de Dev, poderia fazer um video OWASP

@DiasDeDev 8 ай бұрын

Tenho anotado alguns tópicos específicos, como alguns ataques do top 10. :-D

@aercioferreiraneiva8640 8 ай бұрын

gostei das abordagem, só ficou uma duvida no caso de criar um campo versão, não seria mais pratico aplicar Estoque >0, se entendi, as querys vão ser executadas enfileiradas pelo mysql, então o update que for deixar negativo, não vai acontecer.

@DiasDeDev 8 ай бұрын

Ótima pergunta! Pra esse caso em específico, sim. Só verificar o estoque seria suficiente. Mas no mundo real, há mais colunas sendo atualizadas. Talvez uma das colunas tenha sido mantida intacta enquanto outra foi mexida. Talvez uma atualização tenha sido feita em outra parte do produto, e assim em diante. Por isso é mais comum utilizar um timestamp (o famoso updated_at) ou uma coluna de versão. A técnica de optimistic locking não é só pro cenário de compras como o do vídeo. Foi só um exemplo mesmo. :-D

@aercioferreiraneiva8640 8 ай бұрын

@@DiasDeDev eu tenho código para lock aqui, e é bem mais complexo que esse que tu mostrou ae, tiver até que conferir. utilizo uma tabela para controle =/. tenho uma programação paralela que atualiza o numero to ultimo lote de nfe, ae me surgiu uma duvida, não vou causar um problema de deadlock se eu fazer o controle com o controle de transação do mysql? ja que eu vou ter uma conexao com pdo para cada arquivo executado? no meu caso é aberto uma thread para cada execução

@DiasDeDev 8 ай бұрын

Não existe deadlock com acesso a um único recurso.

@AlmirBispo-CSV-Comp-DB 8 ай бұрын

Excelente ! Eu desenvolvi um nosql que ja tem o lock pessimista integrado

@DiasDeDev 8 ай бұрын

Que maneiro!

@reinaldovianna7296 8 ай бұрын

Essa estratégia é interessante, já à vi sendo utilizada em outras linguagens que executam de forma assíncrona. Mas fiquei com uma dúvida, ao invés de utilizar uma coluna auxiliar chamada versão, não poderia no update ser usado a quantidade em estoque recuperada na primeira query? Por exemplo: UPDATE produtos SET estoque = estoque - 1 WHERE id = 1 AND estoque = $quantidade; Ou em uma solução em que permita atualizar mesmo se o estoque não seja exatamente o mesmo, mas maior que 0 : UPDATE produtos SET estoque = estoque - 1 WHERE id = 1 AND estoque > 0;

@DiasDeDev 8 ай бұрын

Muito boa pergunta. Eu até respondi ela em outro comentário. Pro exemplo do vídeo, super resolveria. Mas no mundo real, mais colunas podem ser modificadas, etc. Então a abordagem de optimistic locking é geralmente utilizando um timestamp (famoso updated_at) ou uma coluna de versão.

@matheusanandi 8 ай бұрын

Muito útil 👏

@DiasDeDev 8 ай бұрын

Que bom que gostou. 😁

@fenoke1 8 ай бұрын

Obrigado!

@DiasDeDev 8 ай бұрын

:-D

@marceloramos385 8 ай бұрын

top demais dias, eu tinha esse pensamento de primeiro consultar e depois executar, vai me ajudar bastante. Duvida.... quando o usuário entra no beginTransaction e o select informa que tem estoque, até o usuário realmente fazer a compra, o sistema vai estar segurando o estoque, correto?

@DiasDeDev 8 ай бұрын

Com o SELECT FOR UPDATE dentro de uma transação, outras transações não podem obter lock para o mesmo registro, ou seja, quando outra conexão tentar fazer o SELECT FOR UPDATE também, ela vai ficar esperando a primeira liberar o lock, entende?

@marceloramos385 8 ай бұрын

@@DiasDeDev entendi, muito obg

@cpp33 3 ай бұрын

para complementar, se a fila for grande os timeouts tbm serao.

@leofranca4126 4 ай бұрын

Opa pessoal, alguém saberia se consigo fazer um teste com phpunit testando concorrência?

@DiasDeDev 3 ай бұрын

Eu não conheço nenhuma biblioteca ou coisa do tipo pra isso. Você pode fazer um grande número de requisições de forma concorrente usando Guzzle ou outro cliente e, no final, garantir que o resultado é o esperado.

@leofranca4126 3 ай бұрын

@@DiasDeDev vou fazer assim, obrigado