CommitRetaining / RollbackRetaining
Olá
Eu estava lendo [url=http://www.firebase.com.br/fb/artigo.php?id=156]este artigo[/url] do site Firebase, que fala sobre o uso de ClientDataSets com IBX, e me deparei com algumas dúvidas:
Isso me preocupou um pouco, pois eu uso e abuso dos métodos CommitRetaining / RollbackRetaining. Alguém pode me explicar se o ideal seria abrir mão dos métodos e usar algum outro recurso, como os ClientDataSets sugeridos pelo autor?
Isso é realmente necessário?
Abraços
Eu estava lendo [url=http://www.firebase.com.br/fb/artigo.php?id=156]este artigo[/url] do site Firebase, que fala sobre o uso de ClientDataSets com IBX, e me deparei com algumas dúvidas:
Outra solução que muitos desenvolvedores usam é chamar CommitRetaining ou RollbackRetaining ao invés de Commit ou Rollback. Num primeiro momento isso parece ser a solução ideal, pois não fecha as tabelas e permite ao usuário continuar a ver e alterar os registros selecionados. Entretanto, CommitRetaining e RollbackRetaining não fecham sua transação. Isso significa que você está usando um isolamento de transação do momento e você não pode ver quaisquer alterações feitas por outros usuários até você confirmar (commit) ou desistir (Rollback). Também significa que você desabilitou a “garbage collection” do Interbase forçando ele a manter a transação aberta e as informações dos registros de quando a transação foi iniciada. Isso causa problemas graves de performance em um sistema multiusuário, com muitos usuários alterando diversos registros. Isso é nitidamente o caso em que a cura é pior que a doença.
Isso me preocupou um pouco, pois eu uso e abuso dos métodos CommitRetaining / RollbackRetaining. Alguém pode me explicar se o ideal seria abrir mão dos métodos e usar algum outro recurso, como os ClientDataSets sugeridos pelo autor?
Quando usar ClientDataSets você deve usar um componente de transação separado para cada tabela uma vez que diferentes tabelas podem interagir com o banco de dados simultaneamente.
Isso é realmente necessário?
Abraços
Tnaires
Curtidas 0
Respostas
Edilcimar
25/01/2006
o próprio delphi aconselha a utilizar uma transação para cada query!
GOSTEI 0
Tnaires
25/01/2006
o próprio delphi aconselha a utilizar uma transação para cada query!
É verdade, fui procurar no Help e encontrei a recomendação.
In applications that connect an InterBaseExpress dataset to a client dataset, every query must be in its own transaction. You must use one transaction component for each query component.
E quanto aos métodos Retaining?
Abraços
GOSTEI 0
Orpolonio
25/01/2006
Os Retaining, como disse nossa amada ´Ann´, foi implementado pela borland tipo ´gambiarra´, para atualizações em tela.
Eu modestamente penso, sei exatamente o que vou fazer e uso apenas commit/rollback, depois, retorno apenas o registro alterado. Passo ao usuario a responsabilidade de saber o q vai chamar em tela, nada de trazer + de 500 registros(multi camadas) em um grid.
Eu modestamente penso, sei exatamente o que vou fazer e uso apenas commit/rollback, depois, retorno apenas o registro alterado. Passo ao usuario a responsabilidade de saber o q vai chamar em tela, nada de trazer + de 500 registros(multi camadas) em um grid.
GOSTEI 0
Edilcimar
25/01/2006
eu não uso o retaining
GOSTEI 0