É comportamento transacional sempre necessário fora das bases de dados?

https://stackoverflow.com/questions/296909

08-07-2019
|

Pergunta

Eu não ousaria fazer complexa qualquer coisa em um banco de dados sem transações. Há quase sempre um simples usar o comando embutido. Mas quando você começar a trabalhar com outros dados persistentes você simplesmente não obter este simples para apoiar o uso de transação. Alguns exemplos são

sistemas de arquivos
serviços web (nenhum que eu usei)

Mesmo em dados não-persistentes muitas vezes é útil para desfazer um bloco de trabalho, na sequência de uma exceção. Nenhuma das estruturas de dados padrão que você começa com uma linguagem, as operações de apoio.

O que eu gostaria de saber é, por que são bancos de dados caso especial?

Existem links úteis o tema do comportamento transacional out-side de bases de dados?

Solução

Eu devo discordar respeitosamente: sistemas transacionais não são automaticamente e exclusivamente motores de banco de dados, muito pelo contrário ...

Eu tenho implementado um mecanismo de transação do aplicativo (em .NET) que é distinto de uma transação de banco de dados. Na verdade, é bastante fácil (algumas horas de trabalho, incluindo um conjunto de testes de unidade). É completamente escrito em C # com nenhuma dependência em qualquer funcionalidade de base de dados ou qualquer outro componente. Mas em primeiro lugar algum contexto ...

Este recurso não-banco de dados de transação existe em várias manifestações na plataforma Java, como com EJBs, ESBs, JMS, e muitas vezes em associação com BPM. Algumas dessas manifestações usar um banco de dados subjacente, mas nem sempre e não por necessidade. Outras plataformas têm manifestações semelhantes, tais como MSMQ.

A maioria dos sistemas de controle de versão legado não implementar a semântica de transação ACID. Como DDAA disse, CVS não, mas Subversion (seu sucessor) faz. Visual Source Safe não. Se você pesquisar Subversion, você pode encontrar gráficos de comparação que fazem um ponto desta.

Agora, para o ponto crítico, uma transação de banco de dados ou o seu equivalente não garante lógica de negócios seguro. Embora eu ame Subversion, é ironicamente um grande exemplo deste fato.

Você pode usar Subversion religiosamente, juntamente com um script de construção automatizado (um comando que compila, testes e pacotes de sua aplicação), e ainda cometer uma compilação quebrado ao repositório de controle de origem. Eu já vi isso várias vezes. Claro, é ainda mais fácil com ferramentas de controle de origem não baseadas ACID-transação como VSS. Mas é chocante para muitas pessoas a aprender que é possível com ferramentas como Subversion.

Permita-me por favor para colocar para fora o cenário. Você e um colega de trabalho está desenvolvendo um aplicativo, e usando o Subversion para o repositório de controle de origem. Ambos você está codificando afastado e, ocasionalmente, cometer ao repositório. Você fazer algumas alterações, executar uma compilação limpa (recompilação todos os arquivos de origem), e todos os testes passam. Assim, você confirmar as alterações e voltar para casa. Seu colega de trabalho tem vindo a trabalhar em suas próprias mudanças, então ele também executa uma compilação limpa, vê todos os testes passam, e commit no repositório. Mas, seu colega de trabalho, em seguida, atualiza a partir do repositório, faz mais algumas mudanças, corre uma compilação limpa, ea construção explode na sua cara! Ele reverte suas alterações, atualizações do repositório de novo (apenas para ter certeza), e descobre que uma compilação limpa ainda explode! Seu colega de trabalho gasta o próximo par de horas de solução de problemas da construção e da fonte, e finalmente encontra uma mudança que você fez antes de sair que está causando a falha de construção. Ele dispara um e-mail desagradável para você e seu chefe mútua, queixando-se de que você quebrou a construção e depois descuidadamente foi para casa. Você chega na parte da manhã para encontrar o seu colega de trabalho e seu chefe espera na sua mesa para xingar você, e todo mundo está assistindo! Então você rapidamente executar uma compilação limpa e mostrar-lhes que a compilação não é quebrou (todos os testes passam, assim como na noite passada).

Então, como isso é possível? É possível porque estação de trabalho de cada desenvolvedor não é parte da transação ACID; Subversion só garante o conteúdo do repositório. Quando seu colega de trabalho atualizados a partir do repositório, a sua estação de trabalho continha uma cópia misto do conteúdo do repositório (incluindo suas alterações) e suas próprias alterações não confirmadas. Quando seu colega correu uma compilação limpa em sua estação de trabalho, ele estava invocando uma transação comercial que não foi protegido pela semântica ACID. Quando ele reverteu suas mudanças e realizado uma atualização, sua estação de trabalho, em seguida, acompanhado do repositório, mas a construção ainda estava sem dinheiro. Por quê? Porque a sua estação de trabalho também foi parte de uma transação de negócios separada, que também não foi protegido pela semântica ACID, ao contrário de seu comprometer com o repositório. Desde que você não tinha atualizado sua estação de trabalho para coincidir com o repositório antes de executar vocêr compilação limpa, você não estava realmente construindo os arquivos de origem que existiam no repositório. Se você executou tal atualização, você iria em seguida, descobrir que a construção também falha em sua estação de trabalho.

Agora posso expor meu ponto inicial - transações têm escopo / contexto que deve ser considerado com cuidado. Só porque você tem uma transação ACID não significa que sua lógica de negócio é seguro, salvo se o escopo / contexto da transação ACID ea lógica de negócios corresponde exatamente. Se você está confiando em alguma forma de banco de dados de transações ACID, mas você fazer qualquer coisa em sua lógica de negócio que não está coberto por essa transação de banco de dados, então você tem uma lacuna que pode permitir que um erro comparável e catastrófico. Se você pode forçar sua lógica de negócio para corresponder exatamente a sua operação de banco de dados, então está tudo bem. Se não, então você provavelmente precisará de uma transação de negócios separada. Dependendo da natureza da lógica desprotegido, pode ser necessário implementar seu próprio mecanismo de transação.

Assim, mensagens podem ser transacional, mas o alcance é meramente a mensagem. Em relação ao exemplo acima, o contexto do Subversion é apenas um indivíduo cometer para o repositório. No entanto, a transação comercial é uma compilação limpa, que envolve um escopo muito maior. Este problema específico é normalmente resolvido através da criação de scripts um conjunto de construção com uma verificação geral limpo limpo, de preferência usando uma aplicação de integração contínua (por exemplo, através de CruiseControl ou semelhantes). Nas estações de trabalho do desenvolvedor, que requer cada desenvolvedor de exercer a disciplina para executar uma atualização completa (ou mesmo um check-out limpo) antes de uma compilação limpa.

Então, para recapitular, cada transação tem um escopo ou contexto que limita a sua proteção. transações comerciais muitas vezes incorporam lógica que ultrapassa o âmbito dos mecanismos de transação (como um motor de banco de dados) que comumente usar. Você pode ter que fazer a diferença. Em raras ocasiões, pode até fazer sentido para escrever o seu próprio mecanismo de transação para fazê-lo.

Eu arquitetada uma reescrita de um sistema de negócios críticos para uma empresa de noventa pessoa modesta. Achei necessário para implementar um mecanismo desse tipo, e eu achei a experiência de ser fácil, vale a pena, e gratificante. Eu faria isso de novo, talvez um pouco mais facilmente, mas eu sempre pergunta por que eu não poderia ficar com apenas uma transação de banco de dados.

Outras dicas

Eu acho que a razão que as transações são vistos somente em bancos de dados é que, por definição, os sistemas que fornecem transações são chamados de bancos de dados. Isso soa circular, então eu devo elaborar.

Suporte de transação é o recurso que fornece propriedades ACID . Em termos leigos, isso significa que uma transação é algo que permite a 1. pacote de uma série de operações discretas em um pacote que seja bem-sucedido como um todo ou falhar como 2. ocultar inteiros alterações não confirmadas para usuários simultâneos, de modo que 3. usuários simultâneos tem em todos os tempos uma visão "consistente" do sistema.

Filesystems tradicionalmente oferecem algum mecanismo de bloqueio, mas isso é diferente de fornecer transações. No entanto, todos os sistemas de arquivos têm algumas propriedades atômicas. Por exemplo, se você tiver diretórios /a/ e /b/, e você simultaneamente tentar executar mv /a /b/a e mv /b /a/b, apenas um dos que a operação será bem sucedida, sem comprometer a integridade. O que sistemas de arquivos geralmente não têm, no entanto, é a capacidade de agrupar várias operações em um pacote atômica isolado.

Uma resposta mencionado Subversion. Todos os sistemas de controle de versão sã tem transações. Quando se comprometer com vários arquivos, o sistema quer Aplic a comprometer completamente, ou rejeita-lo completamente (exceto CVS, que eu não considero como sane). A causa da rejeição é sempre uma mudança simultânea. Versão implementadores de sistemas de controle são muito conscientes de manter um banco de dados.

Outra resposta mencionado sistemas de mensagens como transacional . Eu não li o material ligado, mas a resposta em si mencionado apenas entrega atômica de mensagens. Isso não é transações.

Nunca ouvi falar Clojure antes de Brian C. mencionado-lo aqui. Parece-me que é realmente uma implementação de operações fora do contexto de um banco de dados. Aqui o foco é o controle de concorrência, ao invés de manter a consistência dos dados durável.

Assim, com exceção de Clojure, parece que qualquer sistema que transações necessidades ou usa um banco de dados subjacente, ou transformar-se em um banco de dados.

sistemas de arquivos modernos têm transações. Eles são apenas transparente para o usuário final.

NTFS, XFS, JFS, ext3, ReiserFS e todos fazem, só para citar alguns.

E isso é apenas internos para o sistema de arquivos. Muitos sistemas operacionais também apoiar o bloqueio de arquivos (veja rebanho (2) no mundo * NIX, por exemplo) com exclusivo (escrever) e bloqueios compartilhados (leitura).

Edit: Se você pensar sobre isso, sistemas de arquivos não têm níveis de isolamento, como bancos de dados modernos, porque uma vez que você terminar de ler um arquivo, você tradicionalmente fechá-lo se você não bloqueá-lo. Então você reabri-lo quando você quiser escrever para ele.

Clojure usos Software Transactional memória, que usa transações para tornar mais fácil e segura para escrever programas multi-threaded sem fechaduras manuais. Clojure tem estruturas de dados imutáveis ??com referências mutáveis ??para eles, e as transações são necessários para alterar as referências.

sistemas de mensagens são outro exemplo de gestores de recursos transacionais.

Isto é, você pode garantir que um consumidor de mensagens processa com sucesso uma mensagem da fila. Se o processamento falhar, então a mensagem é deixada na fila.

Além disso, um sistema de mensagens pode participar de uma transação distribuída com outro gestor de recursos.

Mais informações em

commits Subversion são transacionais: eles são verdadeiramente atômica, portanto, uma interrupção comprometer não deixa o repositório em um estado inconsistente

Eu tinha a situação I necessário para tratar um sistema de arquivos e um banco de dados como uma unidade transacional.

No meu caso eu só precisava baixar um conjunto de arquivos para o sistema de arquivos. Eu fiz isso através da criação de diretórios aleatórios cada vez, colocando os dados lá, e armazenar o nome do diretório em uma tabela de banco de dados. Por isso todo o meu trabalho banco de dados e o nome do diretório na tabela de banco de dados (= trabalho sistema de arquivos), poderia ser feito em transação de um banco de dados.

http://www.databasesandlife.com/atomic-operations -mais de sistema de arquivos e banco de dados /

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow