Pular para o conteúdo
thiagoetipadrões

Contatos

apps/data-patterns/offline-locking

100 · Dados & Persistência · ≈ 6 min de estudo

Offline Locking

Protege uma edição que dura minutos — o operador abre a tela, pensa, preenche e salva — onde uma transação de banco não cobre o intervalo. O lock otimista detecta no save que alguém salvou antes (versão); o pessimista reserva o registro na abertura, com prazo de validade. Sem nenhum dos dois, quem salva por último apaga a mudança do outro em silêncio.

passos
6
arquivos
6
teste
1
tecnologias
5
Infraestrutura realTypeScriptBunElysiaPostgreSQLDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Back-office de banco digital: dois operadores ajustam o cadastro e o limite de crédito da mesma cliente. Um aumenta o limite, o outro corrige o e-mail a partir da mesma tela aberta minutos antes. Nenhuma das duas mudanças pode sumir, e o operador bloqueado precisa saber quem está editando e até quando.

Planta

Estados
9/9
dono salva, versão + 1LivreEdicaoOtimistaConflito409ReservadoRecusado423operador lê oregistro com a versãosalva com a versãoatual, versão + 1salva com versão antigarecebe o registroatual e reaplicaPOST lock, donoe validadeoutro operador tentaabrir ou salvarunlock ouvalidade expira
9

9 passos — reproduza para seguir o fluxo

  • chamada
  • resposta ou assíncrono
  • falha
  • passo
  • toque num nó para focar
  • repouso ou sucesso
  • transição
  • falha ou recusa
  • Outras plantas de estados

Como funciona

6 passos

Versão otimista ou trava pessimista.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

version+2
  1. 01

    Toda leitura devolve version; o save otimista faz UPDATE ... WHERE version = $2 e incrementa a versão

  2. 02

    Zero linhas atualizadas → 409 com o registro atual, para reaplicar a mudança sobre o dado novo

  3. 03

    A tela de edição reserva com POST /lock: locked_by e locked_until = now() + TTL; outro operador recebe 423 com dono e validade

  4. 04

    O dono salva em /locked-edit, e esse save também incrementa a versão — o otimista segue como rede de segurança

  5. 05

    API e integrações salvam pelo caminho otimista, que também respeita reserva ativa

  6. 06

    Aba fechada sem unlock não trava o registro: a reserva expira sozinha no TTL

Trade-offs

O que se ganha, o que se paga

Técnica Vantagem Desvantagem
Otimista Sem custo de reserva; escala quando conflito é raro O segundo editor refaz o trabalho
Pessimista Conflito nunca aparece no save Reserva esquecida bloqueia até o TTL

apps/data-patterns/offline-locking

6 arquivos

sql/

  • 01_schema.sqlschemacustomers com version, locked_by e locked_until

src/

  • lock_customer.tsSave otimista, reserva, save sob reserva e liberação
  • api_customer.tsRotas com 409 e 423
  • demo.tsdemoOs dois operadores nos dois modos, com expiração da reserva
  • lock_customer.test.tstesteVersão antiga, concorrência, reserva, rede de segurança e expiração contra PostgreSQL real

src/config_customer.ts / src/

  • pool_customer.tsAmbiente validado e pool

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. bun install# dependências
  3. bun run demo# roda o cenário
  4. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
PostgreSQL

Relações

Onde ele se encaixa

Mapa
  1. Offline Locking
  • Combina com2
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com Offline Locking?

Próximo projeto · Dados & PersistênciaBatch Processing (Fechamento de Posição EOD)
Esc

↑ ↓ navegarEnter abrir191 resultados