uncommitted lê?

Question

Eu estava olhando para o potencial de problemas de simultaneidade, em DB, então eu fui ler.Eu encontrei http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0005267.htm e ele menciona o acesso a dados não consolidados.

O acesso a dados não consolidados.Um aplicativo pode atualizar um valor em o banco de dados e aplicação de B pode leia esse valor antes era comprometida.Então, se o valor de a é não mais empenhados, mas desistiu, os cálculos efectuados por B são com base nos lastros (e, presumivelmente, inválido) de dados.

O que...eu pensei que outras sessões (mesmo aplicativo e até mesmo segmento) pode ler os dados que não foi confirmada ainda?Eu pensei apenas a conexão/sessão (não tenho a certeza da minha terminologia) que escreveu os dados para transações não confirmadas podem ler dados não confirmados.

Outras threads realmente ler os dados que não tenha sido cometido?Eu pretendo usar o mysql, mas eu posso usar o sqlite

Answer 1

O que outras sessões podem ler depende de como você configura seu banco de dados. No MySQL, também depende do mecanismo de banco de dados que você usa. O termo que você está procurando (em termos ANSI SQL) é "Nível de isolamento".

Muitos bancos de dados padrão serão padrão para um nível de isolamento em que as leituras nos dados não comprometidos serão bloqueados. Portanto, se a transação A Atualizações registrarem 1234 na Tabela T e, em seguida, a transação B tentar selecionar o registro 1234 antes de um cometidos ou rolares voltar, B bloquear até que A faça uma dessas coisas.

Ver Transações MySQL, Parte II - Níveis de Isolamento de Transação.

Uma desvantagem grave disso é que as operações de atualização em lote que vivem em transações de longa duração (normalmente) podem potencialmente bloquear muitas solicitações.

Você também pode defini-lo para que B verá dados não comprometidos, mas isso geralmente é mal aconselhado.

Como alternativa, você pode usar um esquema chamado MVCC ("Controle de concorrência multiverso"), que dará a diferentes transações uma visão consistente dos dados com base no tempo em que a transação foi iniciada. Isso evita o problema de leitura não comprometido (leitura de dados que podem ser revertidos) e é muito mais escalável, especialmente no contexto de transações de longa duração.

O MySQL suporta MVCC.

Answer 2

Certamente, no SQL Server que você pode, você deve escolher, não é o padrão, mas se você usar o nível de isolamento correto ou a dica de consulta, poderá escolher ler uma linha não confirmada, isso pode levar a problemas e até um duplo Leia a mesma linha em teoria.

Answer 3

Esse artigo menciona o acesso a dados não comprometidos como um dos problemas eliminado pelo gerenciador de banco de dados.

O gerenciador de banco de dados controla esse acesso para evitar efeitos indesejáveis, como:

...

• Acesso a dados não comprometidos.

O mecanismo de armazenamento InnoDB da MySQL suporta vários níveis de isolamento de transações. Para detalhes, vejahttp://dev.mysql.com/doc/refman/5.4/en/set-transaction.html.

Answer 4

Para algumas versões de alguns bancos de dados, definição de consultas para ser capaz de ler não confirmadas que irão melhorar o desempenho, devido à redução de fecho.Que ainda deixa dúvidas de segurança, confiabilidade e escalabilidade para ser respondida.

Para dar um específico, eu costumava trabalhar em um grande site de e-commerce.Eles usaram read lê para o arquivo de catálogo, uma vez que os dados foram acedidas, raro alterada, e não sensível às preocupações sobre a leitura de dados não consolidados.Os dados do catálogo que foi usada para colocar uma ordem que seria re-verificada de qualquer forma.Isso foi no SQL Server 2000, que era conhecido por ter o fecho problemas de desempenho.Em versões mais recentes do SQL Server, o fecho desempenho melhorou, então isso não seria necessário.