Sugestão-Bloquear item (ex. onunload, lock de tabela)

Oi gente,

Há uma tela (caso de uso) que saem vários itens (sub casos de uso) tais como Rejeitar Proposta, Formalizar Proposta e Imprimir Proposta, todavia
só um usuário pode acessar a tela por vez… Como você faria para controlar isso? Nos foi sugerido fazer o seguinte: Quando o usuário seleciona um item
como Rejeitar Proposta, por de trás aciona um método chamado isBloqueio que é um tipo boolean se não tiver bloqueado vai chamar o método insertBloqueio
e depois que o usuário sai ele chama o método deleteBloqueio. Só que há que pequenas falhas pois no mundo real se o usuário sair via botão voltar ou clique
no x do navegador para fechar a janela acabará não acionando o método deleteBloqueio e simplemente o item ficará travado pois não foi destravado com o deleteBloqueio. Foram
comentados o onunload no brownser mas vímos que dará pau futuramente e o lock de tabela que é uma solução a pensar com mais cuidado.

Valeu pela atenção!

Abs,
André AS

O que vc sugere com base nesta estrutura?

abs,
André AS

O post anterior sobre este assunto está dando pau… Não dá pra responder… Isso até o momento que testei…

abs,
André AS

Andre, tudo bem, cara o que exatamente voce esta usando de framework e na camada de persistência e SGBD?

o cenário é o seguinte:

Struts 1
EJB 2
e JDBC

Sem possibilidade de usar outro framework pois está tudo engessado.

Que questão difícil Andre.

Bem, como o usuário pode simplesmente fefchar o browser, perder a conexão com o servidor e a sua aplicação nunca vai ficar sabendo se o usuário saiu da tela, no mínimo, você precisará de um timeout para o bloqueio. Se o usuário estiver mais de 30m por exemplo, dentro da área exclusiva do site, ele pode perder o acesso e ser redirecionado para uma área de acesso irrestrito.

Bem, tirando estes casos nos quais o usuário simplesmente some do site (perdendo conexão, ou fechando browser, ou…) sobram os casos nos quais o usuário navega de uma página para outra saindo da área restrita para a área não restrita. Para pegar estes casos, eu sugiro o uso de filters, ou servlets que sejam associados às páginas *.jsp ou outras que vc ahar melhor. E este filter ou servlet pode tratar as mudanças fazendo os testes que você deseja, mantendo ou removendo o bloqueio.

Você pode fazer esse controle usando Ajax, daí pode verificar quando o usuário entrou ou saiu da página via javascript e chamar um método java que altera sua variável booleana. Quando eu mexia com struts 1 usava DWR pra Ajax, podia tentar com ele.

Legal… É sempre bom discutir opiniões… Estou adora todas a idéias…

fabiocsilva vc tem algum exemplo da utilização do DWR? Aqui usamos o DWR com o AJAX…

abs,
André AS

Não tenho nenhum código porque já faz um tempo que não trabalho com DWR, mas eles tem uma documentação boa, tem até em português:
http://directwebremoting.org/dwr/files/languages/tutorial_DWR-PR.pdf

Deixa eu ler…

Tive pesquisando… Acho que uma solução server-side parece melhor…

Qual sua opinião?

AS

[quote=andredecotia]Tive pesquisando… Acho que uma solução server-side parece melhor…

Qual sua opinião?

AS[/quote]

Se a solução parece melhor, posta aí pra galera saber…

Não é que eu já tenha a solução é que eu acho que Java é melhor do que o Java Script… Entendeu?

O que você pensa sobre?

abs,
André AS

Na verdade você tem que explicar porque precisa desse mecanismo para que seja sugerida a melhor solução. Eu nunca vi uma aplicação web com esse requisito. Talvez o que você precise seja um lock pessimista, que dá pra fazer tanto pela aplicação quanto pelo banco de dados.

Hmmm…

A verdade é que estou como poucas idéias por ser novato em Java… Quais as formas possíveis que vc poderia fazer se tivesse de fazer isto?

Valeu mesmo…

André AS

Cara, tem várias formas de resolver esse problema. A mais trivial seria ter apenas um usuário responsável por essas telas. Mas também seu problema pode ser de fluxo(por exemplo: a proposta inicia com o status “iniciada” e pode mudar para “formalizada” ou “rejeitada”, sendo permitido imprimir apenas propostas formalizadas). Não sei se não permitir que um usuário acesse a tela porque outro já está acessando é um requisito do seu sistema, isso que queria entender.

Exato. É um requisito do usuário…

André AS