Em 3 de março de 2011 23:07, Flavio Henrique Araque Gurgel <fha...@gmail.com> 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.
Impedem sim. Se usados corretamente. O valor do contador deve ser obtido através de um único meio para que o FOR UPDATE funcione, como o uso de uma função com citei no exemplo. Só não impede que um outro SELECT *sem* a cláusula FOR UPDATE leia o mesmo registro. O uso deste recurso requer conhecimento dos níveis de isolação de bancos de dados [1] para entender que este comando faz uma *reserva* do registro aplicando um tipo de LOCK que é diferente do tipo obtido por um simples SELECT, sendo que os dois não são conflitantes. > 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. > Pode ocorrer o estouro de tempo de transação se a variável STATEMENT_TIMEOUT estiver configurada com um valor diferente de zero [2], mas isso certamente apresentaria um erro no client que deve ser devidamente tratado como qualquer comando SQL executado no banco de dados. Quanto à "bola de neve" eu acredito que isto poderia ser tratado com um simples ROLLBACK quando ocorrer um erro na execução de qualquer comando da pilha da aplicação, incluindo erros por timeout. Na minha concepção, aplicações que não fazem isso e mantém o LOCK sobre os registros são mal implementadas. > 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. > Nos quesitos facilidade de implementação e desempenho, as sequencias são imbatíveis. Eu mesmo tenho experiências práticas com isso. Mas reforço que para alguns casos quando os contadores precisam seguir uma sequência infalível, ou seja, sem *pular* um único valor, usar uma SEQUENCE não é o mais indicado. E por falar em bancos de dados sério, outros SGBDs pagos e sérios também tem esta opção e funcionam com toda a maestria que lhes compete implementar os níveis de isolação. [1] http://www.postgresql.org/docs/9.0/static/transaction-iso.html [2] http://www.postgresql.org/docs/9.0/static/runtime-config-client.html -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
