Pois eh, fiz uns testes aqui e o comando LOCK, utilizei (LOCK TABLE tabela_aqui IN ACCESS EXCLUSIVE MODE) e é o comando perfeito para garantir tudo isso.
Porém por algum motivo as vezes ele NÃO libera a tabela. Apenas restartando o postgres. Tem que haver uma forma de manter a sequencia sem furos e sem registros de codigo por exemplo repetidos! Ninguém? =D Em 4 de março de 2011 09:39, Fabrízio de Royes Mello < [email protected]> escreveu: > > > Em 3 de março de 2011 23:07, Flavio Henrique Araque Gurgel < > [email protected]> escreveu: > > >> Sinto muito, mas essa implementação pode ter um efeito colateral. Duas >> transações concorrentes podem "catar" o mesmo valor. O SELECT... FOR >> UPDATE não impede a leitura do registro. >> > > Flávio, > > Até onde eu sei ele bloqueia sim a leitura do "mesmo registro"... > > > ** Sessão 1 > postgres@bdteste=# begin; > BEGIN > postgres@bdteste=# select last_value from my_sequence where sequence_name > = 'teste1_seq' for update; > last_value > ------------ > 3 > (1 row) > > (aqui a transacao ainda esta aberta) > > > *** Sessão 2 > postgres@bdteste=# begin; > BEGIN > postgres@bdteste=# select last_value from my_sequence where sequence_name > = 'teste1_seq' for update; > > (aqui a transacao esta aguardando a liberacao da sessão 1) > > > *** Sessão 3 > postgres@bdteste=# begin; > BEGIN > postgres@bdteste=# select last_value from my_sequence where sequence_name > = 'teste1_seq' for update; > > > (o mesmo ocorre na sessao 3 aguardando a liberacao da 1 e 2) > > > Pode ocorrer um ROLLBACK automático na transação que chegar por último >> na hora fizer o UPDATE da sua função. Se a aplicação não tratar esse >> ROLLBACK (e tentar novamente até conseguir sucesso no COMMIT) isso >> pode se tornar uma bola de neve e um catastrófico "lock geral" numa >> aplicação com muita concorrência. >> >> > Vc quer dizer haver problema entre o SELECT ... FOR UPDATE e o UPDATE na > tabela??? Não entendi muito bem, mas até onde eu sei dentro da PL ele estara > em uma transacao e o SELECT FOR UPDATE irá liberar o registro (unlock) após > finalizar a transação, não é isso?? > > > > >> A implementação de sequências foi inventada exatamente pra isso, sem >> dor de cabeça. Não acho legal tentar contornar por fora algo que um >> banco de dados sério sabe fazer com maestria. >> >> > Concordo plenamente, porém as Sequences garantem Unicidade e não Sequencia > de Valores... e em termos de negócio temos coisas como Nota Fiscal, Empenho, > Autorização de Empenho, Ordem de Compra, etc... que precisam de uma > numeração "sequencial" sem "furos"... > > Por favor, se vc conhece outra alternativa para resolver esse problema > compartilhe conosco... > > Cordialmente, > > -- > Fabrízio de Royes Mello > >> Blog sobre TI: http://fabriziomello.blogspot.com > >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- <table> <tr> <td>oi</td> </tr> </table> Fernando Wobeto Desenvolvedor Web [email protected]
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
