Oi : sobre a ROW_DEPENDENCIES neca, isso é um atributo FÍSICO da tabela que o banco Tem que ser instruído a preencher : se a tabela foi gravada de uma maneira no disco sem a informação o passado já foi , afaik só recriando pra que vc a possa gravar de outra, com informações adicionais okdoc ? Só um ponto aí, muito importante, que vou frisar com *s - na ocasião eu disse "...o ROWSCN, que pode ser usado como identificador de alteração de registros para locks *** otimistas *** em aplicações..."
==> por DEFINIÇÃO, lock Otimista tem esse nome porque ele é um mecanismo criado para aplicações aonde é relativamente RARO se obter conflito por lock, ele "pensa"/julga que a necessidade de controlar dois registros sendo acessados ao mesmo tempo é RARA : mais ou menos o que ocorre em aplicações OLTP padrão. No seu caso, vc Claramente diz que VÃO HAVER edições (e alterações, presumo) simultâneas no mesmo recurso, o sistema pelo jeito FOI pensado assim, então eu Imagino que vc quer um cenário de check in/check out, ou seja,alguém pede pra usar o recurso x, se ninguém está usando a pessoa tem sucesso, e no (curto!) intervalo de tempo enquanto ele não termina de usar ninguém mais pode usar : isso é lógico, pois se A está alterando, como é que B vai ser permitido a alterar também ? Quais alterações deveriam permanecer ao final ? Risco Total de LOST UPDATE - nesse cenário imho simplesmente Não Cabe lock otimista, vc SABE que a esperança otimista é furada... Então eu Acho que para o Seu caso vc precisará é de lock PESSIMISTA - isso não deve causar impacto, já que no RDBMS Oracle por definição : a) locks NUNCA bloqueiam/impedem SELECTs b) não há uma lista de locks possíveis do sistema, locks Não São um recurso escasso a controlar - um banco Oracle com centenas e centenas de locks vão se comportar muitíssimo similar a um com dez locks ativos... Então, se o seu objetivo é impedir que o usuário B altere um registro/recurso enquanto este já está sendo alterado pelo usuário A, vc simplesmente locka o registro e o SELECT que traz os dados é um SELECT FOR UPDATE , aí se alguém já recuperou e está alterando o registro o SELECT falha, e a aplicação joga pro usuário uma mensagem "Este registro está sendo alterado pelo usuário X, por favor tente mais tarde a sua pesquisa"... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Rafael Bahr Esposito da Rocha <rocha.oracle@...> escreveu > > Bom dia, > > Estou com o seguinte problema: > > Possuo uma tabela com edição constante de registros e preciso controlar de > forma eficiente as edições concorrentes pois > trata-se de um processo de aprovação com n níveis e após um usuário realizar > a aprovação outro não pode aprovar em cima > se ambos estiver com o mesmo registro em "tela". > > A opção encontrada por enquanto foi o ora_rowscn. > > A idéia inicial é trazer o ora_rowscn ao buscar os dados, e posteriormente ao > gravar, selecionar o ora_rowscn dos > registros editados para verificar se houve ou não alteração durante o > intervalo em que os dados estiveram em edição. > > Caso tenha ocorrido a edição, parte para a gravação do próximo registro, e > por fim apenas traz uma listagem dos > registros que não foram editados, por terem sido alterados. > > A princípio este tratamento funciona perfeitamente, a não ser por uma > questão, a tabela que eu preciso controlar a > edição concorrente, não foi criada com rowdependencies. > > Como preciso controlar a edição registro a registro, existe a necessidade de > criar esta tabela com o parâmetro > rowdependencies... porém isto se torna inviável visto que esta tabela > encontra-se com grande número de dados e possui > ligações com várias oturas tabelas, impossibilitando a recriação da mesma. > Pelo que entendi algumas documentações é que > senão usar o rowdependencies vários registros ficam com o mesmo rowscn e > quando um é editado todos sofrem alteração... é > isto mesmo? > > Gostaria de saber se existe a possibilidade de alterar esta tabela para > utilizar o parâmetro rowdependencies, sem que > seja necessário recriá-la. > > *Versão oracle: 10.2.0.3* > > Atenciosamente, > > Rafael Bahr > > > > > PS: a idéia de utilizar o rowscn veio a partir do e-mail abaixo enviado pelo > Chiappa. > > -------- Mensagem original -------- > Assunto: Re: Res: [oracle_br] lock na tabela > Data: Sat, 26 Mar 2011 18:10:52 -0000 > De: José Laurindo <jlchiappa@...> > Responder a: oracle_br@yahoogrupos.com.br > Para: oracle_br@yahoogrupos.com.br > > > > Márcio, vc está corretíssimo mas o Élcio frisa que ele está trabalhando em > MODO WEB, e tipicamente quando vc está > desenvolvendo uma aplicação WEB vc não só tem que atender muitos e muitos > usuários simultâneos quanto também (se a > aplicação for acessada externamente) vc Não Tem como garantir que a conexão > de rede entre o servidor e o usuário vai > estar 100% ativa o tempo todo : por causa disso , tipicamente em modo WEB a > aplicação NÂO FICA conectada no banco de > modo constante, ao invés ela conecta, recebe uma informação do banco e já > desconecta, liberando recurso pra outras > sessões, quando necessário enviar/receber mais info do banco conecta de novo > e tão logo possível desconecta.... Além > disso, é típica nesse ambiente a figura do POOL DE CONEXÕES, ie : as conexões > tão lá criadas no banco, quando um usuário > precisa ele "recebe" permissão de uso de uma das conexões do pool, usa > rapidamente e a libera, permitindo que essa mesma > conexão atenda outra sessão, e outra e outra depois... > Em resumo, por causa das causas de escalabilidade e rede acima expostas via > de regra em modo WEB vc NÃO É ATENDIDO pela > mesma conexão, vc Não Pode deixar uma conexão monopolizada por um usuário > eventualmente esperando o lock de outro ser > liberado, então se usa o chamado OPTIMISTICK LOCK : os livros do Tom Kyte > discutem bem isso (e Élcio, fica aqui a *** > Enfática *** recomendação de leitura pra vc) , mas basicamente falando, no > lock otimista cada vez que a pessoa lê um > registro vêm junto um identificador (normalmente numérico) que cresce, E > assim que alguém que tinha o registro na tela > fez alterações e clicka no botão de SAVE, a aplicação vai no banco > rapidamente , vê se o identificador mudou, se não > mudou OK, rapidamente ela manda o UPDATE pro banco E O COMMIT em seguida, e > se preciso altera o identificador (não há > PENDÊNCIA , não há Espera) , aí os outros usuários que leram o registro ainda > estão na tela com o identificador > "antigo", quando alterarem algo e clickarem no SAVE a aplicação vê que o > identificador já mudou, dá um erro de 'registro > já alterado por outro usuário' .... > > Inclusive, no banco Oracle 10g, a Oracle já nos dá uma feature muito útil , o > ROWSCN, que pode ser usado como > identificador de alteração de registros para locks otimistas em aplicações > que não mantém conexão aberta : > http://husnusensoy.wordpress.com/2007/07/28/a-locking-mechanism-in-oracle-10g-for-web-applications/ > explica bem sobre a > técnica, e se vc pesquisar por ora_rowscn no site-referência pra utilizadores > de bd Oracle (http://asktom.oracle.com) vc > acha MUITOS artigos excelentes, como > http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:22948373947565 > , > http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:5809900747879#2194281500346636291 > e > http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:2680538100346782134#2680546500346035086 > . > > Já se a aplicação do Élcio for intranet (ie, modo web mas usado dentro da > mesma rede do servidor, e por um número > relativamente restrito de usuários simultâneos) , aí sim ele pode deixar o > LOCK em aberto, como sugerido - normalmente, > pra ecvitar que o segundo cara fique "pendurado" esperando pelo primeiro, > usa-se o PESSIMISTICK LOCK , ie : na hora que > alguém tenta ler o registro já se mete um FOR UPDATE NOWAIT no SELECT, se deu > sucesso OK, se não deu sucesso o banco > retorna um erro e a aplicação joga pro usuário msg de registro em uso... > > []s > > Chiappa >
