Duvidas sobre níveis de isolamento no firebird 1.0
Pessoal, bom dia.
Postei uma dúvida no forum do Delphi, pois estou com problemas de não salvar alguns registros no firebird 1.0. Há muitas inserções nessa tabela e a concorrencia é muito grande.
Estou trabalhando com generator para gerar o ID da tabela.
O Generator, não ´entra´ em modo transacional como as tabelas ... (dando certo ou não, ele executa) ...
1a. dúvida: O nível de isolamento é para cada cliente ou para o banco de dados inteiro? (Exemplo: se estou tirando um relatorio de clientes em um momento e isolo o banco com readcommited, o primeiro cliente vai ter os clientes somente até aquele momento no relatorio; o segundo cliente pede tb esse relatório, enquanto o primeiro ainda nao libera. O segundo cliente vai estar mais atualizado que o primeiro ou o banco ´congelou´ até aquele momento para todos os clientes ?
2a. Dúvida: Caso eu faça uma trigger para disparam uma storeprocedure para gerar o ID, ou faça a aplicação rodar a SP diretamente sem a trigger, ela entra nesse nível de isolamento tb ? Há possibilidade de mais de um cliente ao mesmo tempo disparar a sp ou a trigger ?
Uma única solução que consigo ver por enquanto é de eu fazer uma tabela física no bd, para guardar o ultimo número do ID e assim que eu fizer o afterpost da tabela, entrar no nível de isolamento... e mesmo assim, não sei se resolve o problema de perda de registros no bd.
Postei uma dúvida no forum do Delphi, pois estou com problemas de não salvar alguns registros no firebird 1.0. Há muitas inserções nessa tabela e a concorrencia é muito grande.
Estou trabalhando com generator para gerar o ID da tabela.
O Generator, não ´entra´ em modo transacional como as tabelas ... (dando certo ou não, ele executa) ...
1a. dúvida: O nível de isolamento é para cada cliente ou para o banco de dados inteiro? (Exemplo: se estou tirando um relatorio de clientes em um momento e isolo o banco com readcommited, o primeiro cliente vai ter os clientes somente até aquele momento no relatorio; o segundo cliente pede tb esse relatório, enquanto o primeiro ainda nao libera. O segundo cliente vai estar mais atualizado que o primeiro ou o banco ´congelou´ até aquele momento para todos os clientes ?
2a. Dúvida: Caso eu faça uma trigger para disparam uma storeprocedure para gerar o ID, ou faça a aplicação rodar a SP diretamente sem a trigger, ela entra nesse nível de isolamento tb ? Há possibilidade de mais de um cliente ao mesmo tempo disparar a sp ou a trigger ?
Uma única solução que consigo ver por enquanto é de eu fazer uma tabela física no bd, para guardar o ultimo número do ID e assim que eu fizer o afterpost da tabela, entrar no nível de isolamento... e mesmo assim, não sei se resolve o problema de perda de registros no bd.
Rod001
Curtidas 0
Respostas
Afarias
01/10/2004
|1a. dúvida: O nível de isolamento é para cada cliente ou para o banco
|de dados inteiro?
Para cada TRANSAÇÃO
|2a. Dúvida: Caso eu faça uma trigger para disparam uma
|storeprocedure para gerar o ID, ou faça a aplicação rodar a SP
|diretamente sem a trigger, ela entra nesse nível de isolamento tb ?
Bom, a triger (e o SP q ela executa) estará na mesma TRANSAÇÃO q o comando q alterou o conteúdo da tabela.
Entretanto, GENERATORS não são ´manipulados´ no contexo de transações.
|Há possibilidade de mais de um cliente ao mesmo tempo disparar a sp
|ou a trigger ?
SIM
|Uma única solução que consigo ver por enquanto é de eu fazer uma
|tabela física no bd, para guardar o ultimo número do ID e assim que eu
|fizer o afterpost da tabela, entrar no nível de isolamento... e mesmo
|assim, não sei se resolve o problema de perda de registros no bd.
Vc não disse qual o seu problema afinal?? ´Perda´ da registros?? O q tem isso a ver com os generators?? Por favor, exclareça.
T+
|de dados inteiro?
Para cada TRANSAÇÃO
|2a. Dúvida: Caso eu faça uma trigger para disparam uma
|storeprocedure para gerar o ID, ou faça a aplicação rodar a SP
|diretamente sem a trigger, ela entra nesse nível de isolamento tb ?
Bom, a triger (e o SP q ela executa) estará na mesma TRANSAÇÃO q o comando q alterou o conteúdo da tabela.
Entretanto, GENERATORS não são ´manipulados´ no contexo de transações.
|Há possibilidade de mais de um cliente ao mesmo tempo disparar a sp
|ou a trigger ?
SIM
|Uma única solução que consigo ver por enquanto é de eu fazer uma
|tabela física no bd, para guardar o ultimo número do ID e assim que eu
|fizer o afterpost da tabela, entrar no nível de isolamento... e mesmo
|assim, não sei se resolve o problema de perda de registros no bd.
Vc não disse qual o seu problema afinal?? ´Perda´ da registros?? O q tem isso a ver com os generators?? Por favor, exclareça.
T+
GOSTEI 0
Rod001
01/10/2004
|Vc não disse qual o seu problema afinal?? ´Perda´ da registros?? O q tem isso a ver com os generators?? Por favor, exclareça.
Ainda sim o problema é a perda de registros ... Percebi que quando os registros nao são gravados, há ´buracos´ de ID´s ... ou seja, quando o registro nao é salvo, o generator executa, porém a aplicacao perde o registro.
Pensei que com a trigger, disparando uma sp, mesmo tendo várias transacoes concorrentes, seriam executadas uma por vez, formando uma fila ...
Ainda sim o problema é a perda de registros ... Percebi que quando os registros nao são gravados, há ´buracos´ de ID´s ... ou seja, quando o registro nao é salvo, o generator executa, porém a aplicacao perde o registro.
Pensei que com a trigger, disparando uma sp, mesmo tendo várias transacoes concorrentes, seriam executadas uma por vez, formando uma fila ...
GOSTEI 0
Afarias
01/10/2004
|Percebi que quando os registros nao são gravados,
Quando o usuário explicitamente CANCELA a operação vc quer dizer (ROLLBACK)
|há ´buracos´ de ID´s ... ou seja, quando o registro nao é salvo, o
|generator executa, porém a aplicacao perde o registro.
Não perde o registro -- cuidado com os termos q usa -- apenas, o valor de generator não retorna. Isso tem q ser assim para poder funcionar em um ambiente multi-usuário.
|Pensei que com a trigger, disparando uma sp, mesmo tendo várias
|transacoes concorrentes, seriam executadas uma por vez, formando
|uma fila ...
Felizmente NÃO
T+
Quando o usuário explicitamente CANCELA a operação vc quer dizer (ROLLBACK)
|há ´buracos´ de ID´s ... ou seja, quando o registro nao é salvo, o
|generator executa, porém a aplicacao perde o registro.
Não perde o registro -- cuidado com os termos q usa -- apenas, o valor de generator não retorna. Isso tem q ser assim para poder funcionar em um ambiente multi-usuário.
|Pensei que com a trigger, disparando uma sp, mesmo tendo várias
|transacoes concorrentes, seriam executadas uma por vez, formando
|uma fila ...
Felizmente NÃO
T+
GOSTEI 0