RLock() no PostGres com SQLRDD

[oribeiro]

Pessoal, como faço funcionar o RLOCK com SQLRDD no PostGres?

Perguntei para o pessoal do xHarbour e tive a seguinte resposta: - O funcionamento está certo rlock manda select for update. Se desejar travar tem que configurar o postgresql pra dar timeout nas Queries. O default e isso desabilitado ou então usar transação

Daí eu estudei o manual do PostGres e encontrei a informação abaixo, mas não entendi nada:

18.11. Lock Management

deadlock_timeout (integer)

This is the amount of time, in milliseconds, to wait on a lock before checking to see if there is a deadlock condition. The check for deadlock is relatively slow, so the server doesn't run it every time it waits for a lock. We optimistically assume that deadlocks are not common in production applications and just wait on the lock for a while before starting the check for a deadlock. Increasing this value reduces the amount of time wasted in needless deadlock checks, but slows down reporting of real deadlock errors. The default is one second (1s), which is probably about the smallest value you would want in practice. On a heavily loaded server you might want to raise it. Ideally the setting should exceed your typical transaction time, so as to improve the odds that a lock will be released before the waiter decides to check for deadlock.

When log_lock_waits is set, this parameter also determines the length of time to wait before a log message is issued about the lock wait. If you are trying to investigate locking delays you might want to set a shorter than normaldeadlock_timeout.

max_locks_per_transaction (integer)

The shared lock table is created to track locks on max_locks_per_transaction * (max_connections + max_prepared_transactions) objects (e.g. tables); hence, no more than this many distinct objects can be locked at any one time. This parameter controls the average number of object locks allocated for each transaction; individual transactions can lock more objects as long as the locks of all transactions fit in the lock table. This is not the number of rows that can be locked; that value is unlimited. The default, 64, has historically proven sufficient, but you might need to raise this value if you have clients that touch many different tables in a single transaction. This parameter can only be set at server start.

Increasing this parameter might cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 17.4.1 for information on how to adjust those parameters, if necessary.

[kleyber]

Oscar,

O conceito de FLOCK() e RLOCK() que conhecemos é aplicável apenas nas tabelas DBF, pois é o nosso sistema quem controla diretamente os DBFs. No caso de bancos SQL, você vai ter que usar transações, pois é o próprio banco quem faz o controle de tudo. Só tente bloquear mesmo o registro se for de fato necessário. Se não, deixe o banco controlar por ele mesmo.

[oribeiro]

Kleyber,

Obrigado pela resposta.

Por exemplo, no DBF quando eu vou abrir a tela de modificação de um cliente eu travo o registro e se outro tenta modificar o mesmo cliente na rede o sistema o avisa de que o registro já está sendo modificado por outro usuário na rede e não o deixa entrar em modo de modificação. Como faço isso com Postgree SQL?

[kleyber]

No caso é só usando mesmo o SELECT ... FOR UPDATE, como no exemplo abaixo:

SELECT * FROM tbl_usuario WHERE

nome like ‘J%’ FOR UPDATE

Neste caso todos os nomes que começam com J estarão bloqueados para a atualização.

[alex2002]

Olá Galera.

Olha, eu coloquei como padrão, em todas as minhas tabelas editáveis, um campo chamado "editando" e nela eu preencho o código de quem está editando no momento (tipo um rlock do dbf). Se o usuário for diferente do logado eu criei uma função para falar até o código de quem está usando, caso contrário eu libero o registro para a pessoa e preencho o editando com o código dela. Ao mudar de registro eu simplesmente limpo o registro "bloqueado" anteriormente.

Basicamente é isso. É como se fosse um RLOCK e funciona legal.

[oribeiro]

A ideia é boa Alexandre,

Quer dizer que eu tenho que fazer na unha o que o velho DBF fazia de modo automático? risos

Vamos pensar na seguinte situação: Se o computador do usuário travar enquanto ele está atualizando, num final de expediente e ele simplesmente desconectar o computador da energia elétrica e for embora. O registro continuará travado? Como você lida com situações assim?

Aguardo, obrigado.

[alex2002]

Olá Oscar.

Então, eu coloquei que ao entrar na tela que deu problema, o sistema limpa o que está marcado. Mas vc pode fazer uma rotina que ao entrar no sistema, varre as tabelas limpando o que o usuário tem travado.

Mas veja bem, eu preferi usar assim. O SQL tem inúmeros recursos para contornar isso. Foi apenas opção minha.

[rochinha]

Amiguinhos,

Tempos atrás eu e o Toya discutimos algo a respeito. Na época era relativo a travamento de registros usando MySQL. Tentei fazer uma pesquisa nos foruns onde estou.

Não consegui uma listagem de meus tópicos aqui no forum. Seria interessante uma característica assim.

Caso eu encontre algo, faço o complemento aqui.

[oribeiro]

Preciso descobrir como fazer isso usando recursos do banco para não ter que controlar isso via rotina de programação.

Acredito que a maior vantagem do banco é a possibilidade de se colocar as regras nele e deixar de fazê-las nos códigos.

Alguém sabe como fazer o RLock() no PostGress ?

O Luiz Culik disse que é para configurar o timeout nas queries porque o default está desabilitado; como se faz isso?