Quais são os problemas de usar transações em um banco de dados?

Question

De esta postagem.Um problema óbvio é escalabilidade/desempenho.Quais são os outros problemas que o uso das transações irá provocar?

Você poderia dizer que existem dois conjuntos de problemas, um para transações de longa duração e outro para transações de curta duração?Se sim, como você os definiria?

EDITAR:Deadlock é outro problema, mas a inconsistência de dados pode ser pior, dependendo do domínio da aplicação.Assumindo um domínio digno de transação (bancário, para usar o exemplo canônico), a possibilidade de impasse é mais como um custo a pagar para garantir a consistência dos dados, em vez de um problema com o uso das transações, ou você discordaria?Em caso afirmativo, que outras soluções você usaria para garantir a consistência dos dados e sem conflitos?

Answer 1

Depende muito da implementação transacional dentro do seu banco de dados e também pode depender do nível de isolamento da transação que você usa.Estou assumindo "leitura repetível" ou superior aqui.Manter as transações abertas por um longo período (mesmo aquelas que não modificaram nada) força o banco de dados a reter linhas excluídas ou atualizadas de tabelas que mudam frequentemente (apenas no caso de você decidir lê-las) que poderiam ser descartadas.

Além disso, reverter transações pode ser muito caro.Eu sei que no mecanismo InnoDB do MySQL, reverter uma grande transação pode levar MUITO mais tempo do que confirmá-la (vimos uma reversão levar 30 minutos).

Outro problema tem a ver com o estado da conexão do banco de dados.Em um aplicativo distribuído e tolerante a falhas, você nunca pode saber realmente em que estado está uma conexão de banco de dados.Conexões de banco de dados com estado não podem ser mantidas facilmente, pois podem falhar a qualquer momento (o aplicativo precisa lembrar o que estava acontecendo e refazê-lo).Os sem estado podem simplesmente ser reconectados e ter o comando (atômico) reemitido sem (na maioria dos casos) quebrar o estado.

Answer 2

Você pode obter impasses mesmo sem usar transações explícitas.Por um lado, a maioria dos bancos de dados relacionais aplicará uma transação implícita a cada instrução executada.

Os deadlocks são causados ​​fundamentalmente pela aquisição de vários bloqueios, e qualquer atividade que envolva a aquisição de mais de um bloqueio pode causar um conflito com qualquer outra atividade que envolva a aquisição de pelo menos dois dos mesmos bloqueios da primeira atividade.Em uma transação de banco de dados, alguns dos bloqueios adquiridos podem ser mantidos por mais tempo do que seriam mantidos de outra forma – na verdade, até o final da transação.Quanto mais tempo os bloqueios forem mantidos, maior será a chance de um impasse.É por isso que uma transação de duração mais longa tem maior chance de impasse do que uma transação mais curta.

Answer 3

Um problema com as transações é que é possível (improvável, mas possível) obter impasses no banco de dados.Você precisa entender como seu banco de dados funciona, bloqueia, transaciona, etc. para depurar esses problemas interessantes/frustrantes.

-Adão

Answer 4

Acho que a questão principal está no nível do design.Em que nível ou níveis do meu aplicativo eu utilizo transações.

Por exemplo, eu poderia:

• Crie transações dentro de procedimentos armazenados,
• Use a API de acesso a dados (ADO.NET) para controlar transações
• Use alguma forma de reversão implícita superior no aplicativo
• Uma transação distribuída em (via DTC/COM+).

Usar mais de um desses níveis no mesmo aplicativo geralmente parece criar problemas de desempenho e/ou integridade de dados.