EJB e Problemas com concorrencia... (se eh que se pode chamar de concorrencia)

plentz wrote:louds, você provavelmente ainda não pegou um sistema com isso. E acredite, dói dar manutenção numa tralha dessas.

Travas otimistas++

Eu realmente estava achando que estava sozinho nisso

HelloWorld Membro desde: 07/07/2006 13:51:57 Mensagens: 14 Offline

Outra opção, na verdade a mais clássica de todas, do tipo que se usava no cobol:
Faça um código sql específico, dando lock de verdade quando a primeira edição acontecer e verificando se o registro está em lock quando a segunda leitura para posterior edição for tentada.

WalterIM wrote:Outra opção, na verdade a mais clássica de todas, do tipo que se usava no cobol:
Faça um código sql específico, dando lock de verdade quando a primeira edição acontecer e verificando se o registro está em lock quando a segunda leitura para posterior edição for tentada.

Algo não cheira bem nessa solução.

WalterIM wrote:Outra opção, na verdade a mais clássica de todas, do tipo que se usava no cobol:
Faça um código sql específico, dando lock de verdade quando a primeira edição acontecer e verificando se o registro está em lock quando a segunda leitura para posterior edição for tentada.

Eu estou fazendo assim também, mas porque me foi solicitado fazer assim.

Em um ambiente com alguma concorrencia vai dar pau. Ou você acha que usuários não saem para tomar cafézinho e largam o terminal idle no meio de um edit por 30 minutos?

Esse tipo de trava até tem aplicações,mas desde que: 1 - Não seja num ponto de muita concorrência e 2 - Os usuários saibam da implicação que um edit pode causar no sistema.

Além disso não esqueça de por no manual do software que o problema do cafézinho existe e pode acontecer, para que não venham depois pedindo sua cabeça.

Olá

Usei esta perfumaria durante muito tempo antes de 1997 quando usava Clipper sem nenhum problema. Só é preciso limitar o tempo que um registro pode permanecer aberto para edição.

Esta discussão se refere a caso de alterações em registros. Se o sistema permitir muitas alterações de registros talvez realmente possa haver algum inconveniente. Onde usei era um sistema de ERP com pouquíssimos lugares em que se podia editar registros. Pelo que me lembro os únicos locais em que se podia alterar registros eram nas tabelas de cadastro e de configuração. Nestas últimas o acesso era restrito aos administradores.

Na tabela de cadastro de clientes, cada vendedor cadastrava o cliente digitando nome diferente. O problema, ao invés de ser editar o mesmo registro, era impedir com busca tipo soundex, a inclusão de um novo quando já existia um antigo com nome digitado parecido.

[]s
Luca

HelloWorld Membro desde: 07/07/2006 13:51:57 Mensagens: 14 Offline

grprado wrote:

WalterIM wrote:Outra opção, na verdade a mais clássica de todas, do tipo que se usava no cobol:
Faça um código sql específico, dando lock de verdade quando a primeira edição acontecer e verificando se o registro está em lock quando a segunda leitura para posterior edição for tentada.

Eu estou fazendo assim também, mas porque me foi solicitado fazer assim.

Em um ambiente com alguma concorrencia vai dar pau. Ou você acha que usuários não saem para tomar cafézinho e largam o terminal idle no meio de um edit por 30 minutos?

Com certeza a melhor solução é a do lock otimista, mas dei essa sugestão porque o colega que começou a thread deu a entender que não poderia usar o lock otimista e teria que dar a mensagem antes do segundo usuário começar a editar.

WalterIM wrote:Com certeza a melhor solução é a do lock otimista, mas dei essa sugestão porque o colega que começou a thread deu a entender que não poderia usar o lock otimista e teria que dar a mensagem antes do segundo usuário começar a editar.

Entendi seu ponto sim

Cada caso tem que ser estudado e bem avaliado. O Pojos in Action tem um capítulo bem legal sobre quatro tipos de lock e quando usa-los.

plentz wrote:

louds wrote:Se isso é tão importante p/ teu sistema, coloca uma tabela no banco indicando que está editando o que. Simples assim.

louds, você provavelmente ainda não pegou um sistema com isso. E acredite, dói dar manutenção numa tralha dessas.

Travas otimistas++

Concordo que optimistic locking é muito melhor nesse cenário. Mas se isso for um requisito do sistema, e fizer realmente sentido?

Sem utilizar uma tabela, uma boa forma de fazer isso seria usando memcached para guardar os locks e Comet style AJAX para garantir que não vamos ter locks mortos.

louds wrote:Sem utilizar uma tabela, uma boa forma de fazer isso seria usando memcached para guardar os locks e Comet style AJAX para garantir que não vamos ter locks mortos.

Opa, dai a coisa começa a ficar bem mais interessante. Mas acho que a primeira coisa a fazer é verificar qual tipo de lock é realmente necessário(se optimistic lock serviria nesse caso) ou se realmente, é requisito do sistema avisar o usuário já quando ele entrar no registro. Perder um tempinho avaliando isso pode te poupar dias de manutenção sofrida no futuro.

plentz wrote:

louds wrote:Se isso é tão importante p/ teu sistema, coloca uma tabela no banco indicando que está editando o que. Simples assim.

louds, você provavelmente ainda não pegou um sistema com isso. E acredite, dói dar manutenção numa tralha dessas.

Travas otimistas++

Pior que é... Imagina se a máquina do cara desliga ou cai a rede sei lá, no meio da edição do registro. O lock ficou no banco. E agora José?!

A Paz!!

Olá

paulohbmetal wrote:Pior que é... Imagina se a máquina do cara desliga ou cai a rede sei lá, no meio da edição do registro. O lock ficou no banco. E agora José?!

Antigamente este problema era resolvido facilmente logo na inicialização dos sistema verificando se havia locks travados. A gente guardava uma listinha em arquivo txt.

Na verdade todo este tópico é meio sem sentido. O que se quer fazer é pura perfumaria.

O modo mais normal de trabalhar com atualizações simultâneas é o modo otimista como muitos já escreveram:

- Se abre o registro para edição de quantos estiverem a fim disto (que geralmente é raro ser mais de um)

- O primeiro que tenta gravar consegue. Os demais são avisados de que o registro mudou e tchau. Em alguns casos recebem a tela com os novos valores no banco.

- Em algumas aplicações se permite gravar também a alteração daquele que demorou mais tempo para salvar o registro com a possibilidade de fazer merge. Nunca vi isto mas sei que existe.

[]s
Luca

Luca wrote:
Antigamente este problema era resolvido facilmente logo na inicialização dos sistema verificando se havia locks travados. A gente guardava uma listinha em arquivo txt.
[]s
Luca

No cliente?!

Quando falei da energia cair é no cliente... Bom, só se locar com o id do usuário que locou e logo na reinicialização o mesmo voltar avisando que existem "tarefas" pendentes sei lá...

A Paz!!

Olá

Sim, no cliente com um arquivo TXT criptografado. E ainda com risco dele estar corrompido durante a queda do sistema. Mas já vi sistemas assim.

[]s
Luca

paulohbmetal wrote:

plentz wrote:

louds wrote:Se isso é tão importante p/ teu sistema, coloca uma tabela no banco indicando que está editando o que. Simples assim.

louds, você provavelmente ainda não pegou um sistema com isso. E acredite, dói dar manutenção numa tralha dessas.

Travas otimistas++

Pior que é... Imagina se a máquina do cara desliga ou cai a rede sei lá, no meio da edição do registro. O lock ficou no banco. E agora José?!

A Paz!!

Ele quer esse recurso, então que se vire com os problemas técnicos para implementar.

Notícias, artigos e o maior fórum brasileiro sobre Java