Pelo que conheço não é uma questão do PostgreSQL e sim de bancos padrão
SQL, pelo menos nos mais populares (SqlServer, Oracle, MySQL, PostgreSQL
e DB2).
O SELECT "simples" nunca é bloqueado (somente se usar for update).
Porém usar todos os SQL com FOR UPDATE pode travar todo o seu sistema
rapidinho já que somente uma transação poderá ler os dados de cada vez,
como em sistema OLTP temos normalmente mais leitura do que alteração a
coisa acaba ficando complicada.
O que tem são os conceitos de transação e de consistência de leitura.
Talvez seja o caso de você pensar o sistema em temos de bancos SQL e não
tentar fazer no PostgreSQL o que um banco como o Adabas faz pois
estruturas de funcionamento e implementação totalmente diferentes.
Leandro Henrique Pereira Neto
Administração de bancos de dados
Charly Frankl escreveu:
Miguel, boa noite...
Para você bloquear os selects, faça todos com FOR UPDATE ... Ai você
tem opções, onde para retornar logo que está "ocupado" utilize NOWAIT.
Att,
2009/8/11 JotaComm <[email protected] <mailto:[email protected]>>
Olá, Miguel
Já comentei no email anterior e fiz uma pequena descrição de como
isso funciona. Você deu uma olhada no exemplo que mandei?
O PostgreSQL não bloqueia a leitura (SELECT), apenas operações de
escrita (UPDATE e DELETE).
2009/8/11 MIGUEL JOSE DE LIMA <[email protected]
<mailto:[email protected]>>
Oi Mário, Este é o problema a leitura nunca é bloqueada.
Fiz os testes pedidos, mas para mim não mudou nada!
Veja:
- Na sessão 1:
db_teste=# BEGIN WORK;
BEGIN
db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
LOCK TABLE
db_teste=# UPDATE tab_material SET desc_serma = 'LAPIS Y'
where codg_serma='10';
UPDATE 1
db_teste=# *** aguardando novo comando ***
- Na sessão 2:
db_teste=# BEGIN WORK;
BEGIN
db_teste=# SELECT * FROM tab_material where codg_serma='10';
codg_empr | codg_serma | id_serma | desc_serma
-----------+------------+------------+------------+--------------+------
202 | 10 | 2020000010 | LAPIS Y |
É isso ai!!!??
Obrigado.
2009/8/11 Mário Oshiro <[email protected]
<mailto:[email protected]>>
Em SQLServer, fiz um teste parecido com o seu.
Qdo vc faz um lock de registro ou trabela, ele nao
bloqueia a leitura
de outras sessoes, ate' que a
sessao de posse do lock, faça um update de algum dado do
registro.
Para bloquear o select que vc fez, faca em seguida um
update com a mesmo
where assim :
db_teste=# SELECT * FROM tab_material where
codg_serma='10' FOR UPDATE;
update tab_material set codg_serma='10' where
codg_serma='10' ;
teste la e depois envie o resultado.
até mais.
MIGUEL JOSE DE LIMA wrote:
> Caros, participantes...
> Sou iniciante neste mundo do PostgreSQL.
> Trabalho com outro Banco de Dados - ADABAS (UNIX
SOLARIS/MAINFRAME),
> mas me incubiram de fazer testes no PostgreSQL para
bloquer registros.
> Então...
>
> Estou precisando de ajuda para bloquear a leitura de um
registro, ou
> seja,
> em um cenário como:
> "Atualização de Estoque de um Material" :
> Antes de atualizar o estoque do material selecionado eu
preciso
> bloquear o registro para que
> nenhuma outra sessão possa obter o dado do registro.
> PRECISO DE UMA LEITURA EXCLUSIVA - TOTALMENTE RESTRITIVA.
> Estou usando o PostgreSQL 8.3.7 para os testes - em linux
> Já li e reli sobre o Isolamento de Transação, mas pode
ser que eu não
> esteja entendendo...???
> Fiz o seguinte teste via psql:
> - Na Sessão "A"
> db_teste=# BEGIN WORK;
> BEGIN
> db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE
MODE NOWAIT;
> LOCK TABLE
> db_teste=# SELECT * FROM tab_material where
codg_serma='10' FOR UPDATE;
> resultado obtido ok!
> *** aqui eu preciso bloquear todos os materiais/itens
(de um pedido)
> - como ex. fiz de apenas 1 (um).
>
> - Na Sessão "B":
> ** Fiz o mesmo SELECT sem a clausula FOR UPDATE:
> SELECT * FROM tab_material where codg_serma='10'
>
> ** aqui eu obtive o resultado ok da leitura.
> Portanto, é aqui, neste ponto que não deveria
permitir nenhuma
> leitura, já que sessão "A" ainda não terminou!
> E AI ALGUÉM PODE ME AJUDAR!?
>
> Obrigado!
>
>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
<mailto:[email protected]>
>
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
_______________________________________________
pgbr-geral mailing list
[email protected]
<mailto:[email protected]>
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________
pgbr-geral mailing list
[email protected]
<mailto:[email protected]>
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[]s
--
JotaComm
http://jotacomm.wordpress.com
http://www.dextra.com.br/postgres
_______________________________________________
pgbr-geral mailing list
[email protected]
<mailto:[email protected]>
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
Charly Frankl
http://javadevilopers.blogspot.com/
[email protected] <mailto:[email protected]>
Linux user #391083
------------------------------------------------------------------------
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa
pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a
seu destinatário e pode conter informações confidenciais, protegidas por sigilo
profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei.
Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente,
esclarecendo o equívoco."
"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a
government company established under Brazilian law (5.615/70) -- is directed exclusively
to its addressee and may contain confidential data, protected under professional secrecy
rules. Its unauthorized use is illegal and may subject the transgressor to the law's
penalties. If you're not the addressee, please send it back, elucidating the
failure."
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
