Fórum Transação quando depende do tempo de conclusão do usuário!!! #43479

26/03/2004

0

Caros colegas forueiros. :D

Preciso tirar uma dúvida quando preciso que uma transação só seja commitada após um longo trabalho do usuário.

Bom, talvez explicando o contrário (do que está acima) seja melhor a explicação do que eu quero:

Quando todo procedimento de alteração entre várias tabelas estão em um único evento, é fácil controlar uma transação, pois inicia, processa e commita. Tranquilo, tudo num segundo só.

Agora veja bem, um usuário vai carregar em um formulário varios valores e vai ficar trocando de lugar entre eles, antes de iniciar a troca, inicio uma transação, só que o usuário com sua velha fama, consegue deixar o formulário aberto, e com a transação iniciada e vai tomar um café... daques de 20 minutos (se for funcionário público claro) e depois volta pra terminar a transação.... só que com isso, quando ele pensar que está concluindo uma transação, ou, ele ´pendurou´ as tabelas que começou a trabalhar, ou os dados que ele pensa estarem da forma com que iniciou já não são mais os mesmos.

Espero que tenham entendido e como poderia evitar esse problema, já que tenho certeza que tudo isso pertence a uma única transação, ou tudo é feito, ou deve se desfazer tudo!

Qual seria a saída?

Agradeço a todas as ajudas.

Claudio Sam.


Claudio Sam

Claudio Sam

Responder

Posts

27/03/2004

Logado

Após iniciada uma transação aos registros envolvidos ficam agusrdando até q esta trasação termine, ou seja, naum poderá ser iniciada uma nova transação destes registros enquanto a outra naum for fechada.

Faça um teste com duas máquinas pra ver o q acontece.... eu sinceramente te falo isso por tudo q já li e vi aqui mesmo no fórum... pode ser q eu tenha esquecido de alguma coisa....


Responder

Gostei + 0

27/03/2004

Afarias

|Preciso tirar uma dúvida quando preciso que uma transação só seja
|commitada após um longo trabalho do usuário.

A melhor saída para seu caso, na minha opnião é usar tabelas de memória (ou outros métodos com o mesmo conceito) -- que seria::

1- vc abre a transação e carrega os dados que vai trabalhar (em uma tabela de memória ou objeto)

2- então vc comita a transação

3- o usuário trabalha com os dados em memória

4- quando o usuário for gravar os dados no banco, vc pega os valores da tabela de memória ou objeto, constroi os SQLs (insert, update, delete), abre uma transação, executa as operações e então ´comita´ a transação

Isso traria as seguintes vantagens::

a) transações curtas otimizando o banco (no caso de IB/FB principalmente)
b) não haveria bloqueio de registro (caso do usuário fazer 1 alteração (update) e só commitar um tempo depois)

Desvantagens::

c) Não há possibilidade de bloquear um regsitro (caso isto seja o desejado)

A grande questão aqui é quanto a 2 usuários atualizarem o mesmo registro neste meio tempo -- o 2º usuário a alterar o registro não vai ver q o registro não tem mais o valor q tinha quando carregou -- Isso ocorre usando qualquer abordágem -- um forma de contornar isso (se desejado) é fazer o update colocando os campos alterados no WHERE então caso o registro não esteja igual não haverá atualização e o usuário poderá ser avisado.


|Após iniciada uma transação aos registros envolvidos ficam agusrdando
|até q esta trasação termine, ou seja, naum poderá ser iniciada uma
|nova transação destes registros enquanto a outra naum for fechada.

Falso... vc pode ter várias transações simultâneas nos mesmo registros (concorrência)... acho q o q vc leu foi::

Uma vez alterado um registro, este fica bloqueado para outras alterações na rede até q seja efetuado um commit ou rollback da transação q fez a atualização.


T+


Responder

Gostei + 0

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar