o unico motivo que me fez pensar em usar o LOCK foi por exemplo que um certo script PHP precise pegar o ultimo codigo +1 em uma tabela. Após começa a fazer update em outras tabelas usando tal codigo como referencia e no final de tudo gera realmente um registro na primeira tabela com o codigo.
O problema é que podemos ter em outra estação algum usuário efetuando o mesmo procedimento, então ele pegaria o mesmo codigo+1 e jogaria nos seus registros esse código. Qual seria a alterativa fora o LOCK? Muito obrigado pela presteza. Fernando Em 2 de março de 2011 16:12, Euler Taveira de Oliveira <[email protected]>escreveu: > Em 02-03-2011 15:28, Fernando Wobeto escreveu: > > pg_query('BEGIN'); > > pg_query('LOCK TABLE tabela1'); > > pg_query('SELECT codigo +1 FROM tabela1'); > > pg_query('INSERT INTO tabela2(var1,var2,var3,var4)VALUES(1,2,3,4,5)'); > > pg_query('UPDATE tabela3 SET var1=1'); > > pg_query('COMMIT'); > > > > > > por qual motivo um codigo desses no final das contas deixaria a tabela1 > > travada por causa do lock. > > > O COMMIT ou ROLLBACK não ser executado? O tempo de espera (timeout) da > página > web é alto após o pedido de cancelamento pelo usuário? Algum deadlock > causado > por outra sessão fazendo um travamento nas tabelas tabela2 ou tabela3? > > Eu não aconselharia o uso do LOCK TABLE. Ele causa muito mal para uma > aplicação que permite o acesso concorrente dos dados (quase todas hoje em > dia). Aconselho-te pensar novamente se isso é realmente necessário. > > > -- > Euler Taveira de Oliveira > http://www.timbira.com/ > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Fernando Wobeto Desenvolvedor Web [email protected]
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
