Miguel,
Talvez eu seja tão "velho" como você já que também programei em clipper
e num banco de mainframe (DMSII - UNISYS) que é da mesma época de
tecnologia do ADABAS, apesar do ADABAS se considerar um banco de lista
invertidas e hoje em dia "relacional".
Se usar o SELECT FOR UPDATE e os comandos de DML (insert, update e
delete) vai funcionar.
A questão é quando você vai precisar prender o registro para atualizar o
saldo.
Imagine um site de vendas como o submarino. Eu usuário estou olhando um
produto naquele momento o registro precisa está liberado para consulta,
já que eu estou somente consultando. Aí eu resolvo fazer a compra, no
momento que eu confirmo que quero comprar é que o sistema faz "lock" por
alguns milisegundos do registro para atualizar o saldo.
Lógico que isto pode causa uns comportamentos estranhos, tipo quando
consultei tinha saldo mas na hora de confirmar a comprar não tinha mais
e a compra não é confirmada (isto já ocorreu comigo na vida real num
sistema destes de compras online).
Mas isto é necessário quando estamos trabalho com milhares de acessos
simultâneos de sistemas OLTP.
Seria assim
sessão 1 - consulta sem for update
sessão 2 - consulta sem for update
sessão 1 - faz o select for update e começa a transação para alterar o saldo
sessão 2, sessão 3 e sessão 4 - consultam sem for update e conseguem
consultar o saldo antigo
sessão 2 - faz o select for update para tentar alterar o saldo também
recebe um lock. (Aí o programa precisa definir o que fazer esperar ou
cancelar logo tudo).
sessão 1 - termina de altera o saldo (COMMIT na trasnsação)
sessão 2 - consegue fazer o select já em cima do valor novo alterado
pela sessão 1.
A questão é que em bancos SQL não precisamos no preocupar tanto com o
controle de lock e de transação, normalmente o funcionamento padrão do
banco resolve, pelo menos para sistemas mais simples.
Leandro Henrique Pereira Neto
Administração de bancos de dados
MIGUEL JOSE DE LIMA escreveu:
Bom dia,
Leandro, eu concordo com vc, talvez tenho que aprender a conviver com
os conceitos
de Banco de Dados Relacional e SQL..., mas confesso a vc que para mim
é meio
decepicionante, não conseguir LOCAR um registro para leitura e poder
tratar isso.
Até velho bom antigo CLIPPER fazia isso, vc imagina eu acostumado a
fazer isso
por logos anos, também com ADABAS.
Mas eu gostaria, se possível, de lhe perguntar: COMO É POSSÍVEL ATUALIZAR
UM SALDO DE QUALQUER COISA (estoque/contacorrente), SEM PRENDER O
REGISTRO PARA LEITURA? COMO POSSO SIMULAR ISSO?
Obs.: Como algumas pessoas já tentaram me ajudar..., informa mais uma
vez que
o SELECT ... FOR UPDATE não bloquei leitura!
Obrigado!
2009/8/11 Leandro Henrique Pereira Neto
<[email protected]
<mailto:[email protected]>>
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]
<mailto:[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]
<mailto:[email protected]>
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
------------------------------------------------------------------------
_______________________________________________
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
