Realmente Leandro, trabalhei muito com CLIPPER e desde 1984, até hoje, trabalho com NATURAL/ADABAS. Vou ter que me reciclar, e aprender muita coisa nova sobre SQL e Bancos Relacionais. Mas o que é vida, se não, um eterno aprendizado. Mas foi muito importante esta minha primeira participação ativa no grupo.
Valeu, Muito Obrigado. 2009/8/12 Leandro Henrique Pereira Neto < [email protected]> > 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]> > >> 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]> >> >>> 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]> >>> >>>> 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]> >>>> >>>>> 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] >>>>> > 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> pgbr-geral mailing list >>>> [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] >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> >>> >> >> >> -- >> Charly Frankl >> http://javadevilopers.blogspot.com/ >> [email protected] >> Linux user #391083 >> >> ------------------------------ >> >> _______________________________________________ >> pgbr-geral mailing >> [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 >> >> > ------------------------------ > > _______________________________________________ > pgbr-geral mailing > [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 > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
