Gerenciamento de Dados - E que tal o ambiente multi-usuário?

Quando nós desenvolvemos uma aplicação para uma situação multi-usuário, na qual é possível que dois usuários acessem os mesmos dados ao mesmo tempo, a necessidade de desenvolvimento usando transações é maior.

Vamos dar uma olhada nisto com o mesmo cenário simples. Vamos assumir que Fred quer transferir os últimos $50 de sua conta poupança para sua conta corrente (isso parece familiar?), mas sua esposa Wilma está em outra agencia do banco e está sacando $50 da conta corrente para comprar as verduras da semana.

O que acontece? Neste caso, o cenário não é tão simples como possa parecer:

Fred	Wilma
Lê o total da conta poupança
Subtrai $50 da conta poupança
Lê o total da conta corrente
Soma $50 ao total da conta corrente	Lê o total da conta corrente

Ao mesmo tempo em que Wilma está verificando o saldo atual da conta corrente, a fim de sacar o dinheiro, Fred está depositando dinheiro na conta corrente.

Neste caso, ela provavelmente verá que o dinheiro ainda não foi transferido. Ela então verificará o saldo da conta poupança e o que ela verá? Está vazia (lembre que nós mencionamos que Fred está sacando os últimos $50).

O resultado agora será uma conversa zangada entre o feliz casal.

No mundo das transações, este cenário seria ligeiramente diferente. Quando o processo é executado como uma unidade lógica única, um subproduto útil disto é que quaisquer dados atualizados são bloqueados até que a transação tenha sido concluída.

Neste caso, Wilma ainda provavelmente veria que o dinheiro não teria sido transferido, e quando ela verificasse o saldo da conta poupança, ela veria que o dinheiro ainda está na conta. O telefone tocando para Fred teria um tom diferente.

Deve ser observado que os bloqueios são acumulativos dentro da transação. Por exemplo, depois de atualizar um certo registro (o qual é bloqueado como um resultado), o usuário atualiza um segundo registro. Ambos os registros são parte da transação e serão bloqueados até a transação ser ou aplicada (committed) ou cancelada (rolled back).

Supondo que Wilma decide que ao invés de ligar para Fred, ela vai transferir o dinheiro ela mesma. Mas pelo tempo que isso leva para acontecer, a transação com o Fred tenha sido completada (committed). Agora, neste caso, quando ela tentar verificar o saldo atual da conta poupança, o total já terá sido atualizado. Ela pode agora alegremente sacar o dinheiro da conta corrente.

O que de fato acontece neste caso em particular realmente depende do DBMS usado, mas o propósito aqui é dar uma simples visão das transações.

Fonte: "Data Management.pdf", arquivo acompanha a instalação do eDeveloper 10, em inglês.