Http e Concorrência

5 respostas
guariba

Por Http ser um protocolo stateless não há como o lado servidor saber se um usuário ainda está utilizando o sistema. Então suponhamos que um dos usuários esteja alterando um produto de código 2. Quando outro usuário tentar alterar este mesmo código o sistema irá informá-lo que já existe um usuário manipulando a informação que ele gostaria de alterar.

Ora, se o outro usuário simplesmente fechar o navegador, o sistema não teria como ser notificado e o registro permaneceria bloqueado. Em outra situação mais “light”, o usuário poderia simplesmente ter largado a aplicação e ido tomar um cafezinho.

Diante disto como um sistema Web “sabe” que uma sessão está ativa? Num portal mui provavelmente cada usuário altera suas próprias informações, então acho que não teria muito galho. Mas numa intranet, com vários usuários utilizando possivelmente as mesmas informações, como a coisa funciona?

5 Respostas

Rafael_Steil

Bom, isso eh mais um problema da tua aplicacao do que do http.

Voce pode resovler o problema com um SessionListener. ( vide manual da servlet api )

Rafael

louds

Http é um protocolo stateless, logo sua aplicação tem que ser programada dessa forma, que sua session é apenas um suplemento da requisição e não estado nno servidor.

A melhor forma de resolver isso é usando optimistic locking.

guariba

Eita, traduz…

louds

Em uma aplicação web você jamais deve fazer 1 transação durar mais que 1 request http, senão está condenado a ter problemas.

A melhor solução, IMHO, é usar optimistic locking, onde voce usa versionamento como forma de controlar concorrencia.

Exemplo (usando pseudo-JDBC):

//sem optimistic locking:
statement.executeUpdate("update usuario set usuario.senha = 'bingo' where usuario.id = 1234");
transaction.commit();

//com optimistic locking:
//quando carregamos esse registro estavamos com a versão 10.
int total  = statement.executeUpdate("update usuario set usuario.senha = 'bingo', usuario.versao = 11 where usuario.id = 1234 and usuario.versao = 10");
if(total == 0) {
  transaction.rollback();
  throw new OptimisticLockingFailureException("usuario com versão mais antiga");
} else
 transaction.commit();

Optimistic locking tem alguns problemas entretanto:

-código fica mais dificil de manter (dica: use 1 framework de persistencia que suporte OL como hibernate)
-possibilidade de falhar transações grande.

guariba

Ok, entendido!

Criado 12 de julho de 2004
Ultima resposta 13 de jul. de 2004
Respostas 5
Participantes 3