Duvida sobre Instance Variables e Thread-Safes

Esse treco do single thread model foi a maior idiotisse que o pessoal da sun criou.
Tudo que eh autor serio que eu ja vi fala , explica, mas diz que eh inutil.
Primeiro o SingleThreadModel, seja ele por alocacao ou pool, NAO EH A MESMA COISA QUE SESSAO.
Nao existe nenhuma garantia que voce pegue o mesmo objeto na segunda requisicao.
Mas entao Tanque, para que serve esse lixo:
Te respondo, numa servlet comum o container, em geral cria soh uma instancia do servlet e todos os clientes usam ela. Se eu usasse atributos, todas as instancias compartilhariam esse atributo (mas nao use atributos, de qualquer forma). Quando precisamos fazer algo complexo dividimos a coisa em metodos e passamos parametros para esses metodos.
Agora, sempre tem aquele mane preguicoso e chato. Nao, eu nao quero usar parametros, eu quero que o metodo invocado leia os dados que precise via atributos da classe. Ou seja o metodo pricipal doGet seta um atributo, chama o outro metodo da classe e esse outro metodo le o atributo setado pelo doGet. Neste cenario eh necessario fazer o uso do SingleThreadModel, pois senao esse atributo poderia ser modificado por outro cliente. Tudo porque o mane preguicoso e chato nao quis passar a naba como parametro, e sim como atributo da classe.

Sempre vai vir aquele cara falando de purismo de orientacao a objeto: “ah, mas como que um servlet, que eh uma classe, nao pode ter atributos, cade a orientacao a objetos”. Bem, realmente para ele o tal de SingleThreadModel resolveria, mas eu acho muito mais interessante ele criar sua arquitetura orientada a objeto desvincilhado dos servlets, em outra camada, com um acoplamento mais baixo, como prega qualquer metodologia moderna de engenharia de software.

Por esses motivos SingleThreadModel soh vai servir para passar na sua certificacao ai.

Realmente o servlet SingleThreadModel é meio inútil, como front-end da aplicação.

Imaginem uma aplicação real e séria onde uns 1000 usuários acessam “sequencialmente” um servlet, é o que o SingleThreadModel proporciona, um service synchronized. Em vez de compartilhar a CPU entre os usuários estaríamos restringindo os recursos somente a um usuário de cada vez.

Porém, em algumas aplicações, também há recursos que somente podem ser acessados sequencialmente, ou seja, dois usuários não podem dispor desse recurso ao mesmo tempo.

Imaginem 1000 usuários logando em um arquivo texto ao mesmo tempo ! Só teria lixo dentro desse arquivo. Este é apenas um exemplo de aplicação, com certeza não é o melhor

“net_sandro”:

Realmente o servlet SingleThreadModel é meio inútil, como front-end da aplicação.

Imaginem uma aplicação real e séria onde uns 1000 usuários acessam “sequencialmente” um servlet, é o que o SingleThreadModel proporciona, um service synchronized.

Soh para exclarecer, a especificacao que trata de SingleThreadModel especifica que um servlet neste modo deve ser thread-safe. O sequenciamento eh uma opcao, mas nao a unica, eh possivel gerar um pool de servlets singlethreadmodel ou ate instanciar um novo servlet a cada requisicao (bad idea).

Sim, com certeza a recursos que nao podem ser compartilhados, como o arquivo texto mencionado por voce. O melhor, nesse caso, eh sincronizar somente o acesso ao arquivo texto e nao o servlet inteiro. Desta forma voce aumenta o paralelismo de sua aplicacao.

Me corrijam se estiver errado, mas essa coisa de setar valores em variáveis de instãncia do Servlet para usá-las em outros requests não seria um trabalho para o setProperty do HttpSession ?
Não é conceitual que informações sobre a requisição de cada cliente vá para o objeto de sessão, e informações referentes a instancias de Servlets fiquem em instance variables ou mesmo no ServletContext ? pois em ambas as situações elas podem ser sincronizadas.
Se não é nada disso , desculpem pois não entendi a discução.

Claudio Gualberto.
SCJP 1.4

Só adicionando meus 0.02: SingleThreadModel vai ser deprecado na próxima versão da especificação de Servlets (2.4). Se é que esta especificação já não saiu

Todo caso, o mero uso de SingleThreadModel já indica preguiça e faz você perder pontos com a galera “cool”. Seja cool, não use SingleThreadModel

Que bom que vão depreciar isto…
Nunca usei pra NADA!!!

Depreciar nao, tem eh que arrancar mesmo.
Isso eh um ponto que eu acho de certa forma muito ruim no java, esse treco de depreciacao.
Primeiro, nao deveriam, na teoria, ter erros de concepcao das coisas. Sim, eu sei que os serer humanos sao sujeitos a falhas, mas na biblioteca de java isso chegou a virar um exagero. Soh para citar alguns exemplos, temos o java.util.Date, que nao previa um suporte adequado a Regionalizacao e Localizacao e sem falar no sistema de thread, que algum imbecil achou bom ter um stop e suspend, e nao pensou que poderiam ocorrer alguns deadlocks meio estranhos.

O pior eh que esses lixos ainda estao la, para que algum programador novato possa usar. Tem que arrancar mesmo. Nao quero comparar com a M$, mas tem que deixar de ter tanta compatibilidade assim. Compatibilidade binaria ate concordaria, uma parada compilada no 1.1 tem que rodar nas proximas versoes, mas o compilador tinha que bloquear o uso de deprecateds, na minha humilde opiniao.

Mas o compilador avisa que algo esta depreciado…
Se bem q para um usuario novato, ele vai querer ver se tah funcionando, se tiver ele esquece akilo!

“duardor”:

Mas o compilador avisa que algo esta depreciado…
Se bem q para um usuario novato, ele vai querer ver se tah funcionando, se tiver ele esquece akilo!

Uma vez vi uma usuaria de C/C++ usando um toolkit grafico da sun chamado guide. Ai notei que ao compilar o projeto dela dava uns trocentos warnings. Sabe qual a solucao que ela descobriu para o problema? -Wall. Desabilitar todos os warnings.
Fantastico, nao?

“tanque”:

-Wall. Desabilitar todos os warnings.
Fantastico, nao?

-Wall não desabilita os warnings … pelo contrário, exibe tudo quanto é warning possível! (eu sei eu sei, deu pra entender a mensagem, mas só pra ser chato )