Prezado Alex,
Primeiramente gostaria de me desculpar pela afirmação abaixo. Realmente não
tem nada a ver o fato de usar "SingleThreadModel" com o travamento do
Applet. Respondi o texto abaixo porque recebi alguns erros de exception no
passado, quando não implementei este modelo e fixei a idéia de que só
conseguiria estabelecer o STREAM desta forma.
Observando os exemplos do site http://www.servlets.com existem 3 soluções:
Via STREAM sem ser SingleThreadModel, via Sockets e via RMI.
Implementei a 1. opção e o Applet continuou travando se eu modificar mais
rapidamente a caixa de seleção. Aparentemente o Applet não consegue
administrar o fluxo de dados intenso entre o Input e o Output do STREAM,
causando o travamento.
Mesmo simulando uma única conexão, se eu ficar clicando na seta para baixo a
fim de alterar a caixa de seleção mais rapidamente o Applet trava, perdendo
o controle sobre a operação de troca de dados com o Servlet.
Vou tentar implementar as outras alternativas e ver se consigo um melhor
resultado, ok?
[]'s
Carlos Campos
> ----- Mensagem original -----
> De: Carlos Campos
> Enviada em: Sexta-feira, 30 de Março de 2001 16:58
> Para: '[EMAIL PROTECTED]'
> Assunto: RES: [java-list] Trocando dados entre Applets e Bancos de
> Dados
>
> Oi Alex,
>
> Creio que vc realmente não entendeu o meu objetivo.
>
> O servlet precisa implementar o modelo "SingleThread" para estabelecer uma
> comunicação contínua e única via stream entre o Applet e o Servidor. Se vc
> ignorar o modelo "SingleThread" aparentemente não é possível fechar um
> canal de comunicação entre o seu Applet e o Servlet comum, tendo em vista
> que o servlet não saberia para qual applet enviar a resposta, gerando uma
> exception. Há menos que vc utilize o redirecionamento padrão de páginas,
> onde cada thread do servlet gera uma página de retorno para cada
> requisição.
>
> Neste caso específico eu não estou querendo gerar páginas de retorno do
> meu servlet. Estou querendo ficar na minha página inicial, PARADINHO, com
> o meu Applet conversando com um Servlet no servidor que atenderá todas as
> minhas requisições, entendeu ???
>
> Estou pesquisando, por indicação do Handerson Gomes, o site
> http://www.servlets.com onde existem alguns exemplos deste tipo de
> comunicação via SOCKETS e via RMI utilizando algumas classes adaptadas.
>
> Vou tentar me virar sozinho, ok?
>
> Qualquer coisa eu grito!!!
>
> []'s
>
> Carlos Campos
>
> ----- Mensagem original -----
> De: Alex Dornelas Felipelli [SMTP:[EMAIL PROTECTED]]
> Enviada em: Sexta-feira, 30 de Março de 2001 15:40
> Para: [EMAIL PROTECTED]
> Assunto: Re: [java-list] Trocando dados entre Applets e
> Bancos de Dados
>
> Eu ainda não entendi o porquê de o Servlet ser SingleThread.
> O que tem isso a ver com o "pula pula de páginas HTML"? Você mudar de URL,
> não tem nada a ver com a instancia da Servlet que você está acessando.
> Não sei se eu entendi direito o seu problema, mas eu tenho impressão que
> você poderia deixar de implementar o SingleThreadModel. Porque você
> colocou
> isso inicialmente?
>
> Não entendo de RMI, mas deve haver uma maneira de fazer o que você está
> querendo mesmo, já que você terá um client (applet) acessando remotamente
> o
> objeto no seu servidor.
>
> Alex
>
> ----- Original Message -----
> From: "Carlos Campos" <[EMAIL PROTECTED]>
> To: "'Lista SouJava'" <[EMAIL PROTECTED]>
> Sent: Friday, March 30, 2001 2:05 PM
> Subject: ENC: [java-list] Trocando dados entre Applets e Bancos de Dados
>
>
>
>
> > ----- Mensagem original -----
> > De: Carlos Campos
> > Enviada em: Sexta-feira, 30 de Março de 2001 14:02
> > Para: '[EMAIL PROTECTED]'
> > Assunto: RES: [java-list] Trocando dados entre Applets e Bancos de
> > Dados
> >
> > Oi Alex,
> >
> > Agradeço por vc ter repondido o meu e-mail.
> >
> > Eu não utilizo a interface "SingleThreadModel" para todos os servlets,
> mas
> > apenas para este tipo de comunicação onde o Applet fica recebendo e
> > enviando os dados para o Servlet sem ocorrer o redirecionamento de
> página.
> >
> > Ou seja, me corrija se eu estiver errado, mas quando se utiliza Servlets
> > vc envia solicitações ou dados via GET ou POST e executa um Servlet no
> > servidor que processa a informação e te devolve uma página HTML com os
> > resultados, certo?
> >
> > Neste caso específico, estou evitando o "pula pula de páginas HTML". O
> > usuário carrega a Applet uma vez numa página HTML, e acessa os dados no
> > lado Servidor sem que seja necessário trocar de página HTML, entendeu
> ???
> >
> > Parece que existe uma possibilidade de implementar os Servlets
> > Multithreads via pacotes RMI, de modo a atender especificamente esta
> > necessidade, mas ainda estou a busca de um exemplo, ok?
> >
> > Qualquer orientação me avise e muito obrigado amigo.
> >
> > []'s
> >
> > Carlos Campos
> >
> > ----- Mensagem original -----
> > De: Alex Dornelas Felipelli [SMTP:[EMAIL PROTECTED]]
> > Enviada em: Sexta-feira, 30 de Março de 2001 12:13
> > Para: [EMAIL PROTECTED]; 'Handerson Gomes - Java'; 'Lista
> > Webmasters'
> > Assunto: Re: [java-list] Trocando dados entre Applets e
> > Bancos de Dados
> >
> > Esse "travamento" é devido ao limite de instancias de servlet no seu
> > Servlet
> > Server
> > Como o seu servlet é SingleThreadModel, o seu Server criará uma
> instancia
> > dele para cada requisição simultânea.
> > Esse limite de instancias, normalmente, pode ser configurado no seu
> > Servlet
> > Server.
> > Porém, o ideal seria você tornar o seu Servlet MultiThread.
> > Porque você implementa a interface SingleThreadModel? Uma das vantagens
> do
> > Servlet é justamente você poder ter apenas uma instancia e várias
> threads
> > para cada request.
> >
> > Alex Felipelli
> >
> > ----- Original Message -----
> > From: "Carlos Campos" <[EMAIL PROTECTED]>
> > To: "'Lista SouJava'" <[EMAIL PROTECTED]>; "'Handerson Gomes -
> > Java'"
> > <[EMAIL PROTECTED]>; "'Lista Webmasters'"
> <[EMAIL PROTECTED]>
> > Sent: Friday, March 30, 2001 9:29 AM
> > Subject: [java-list] Trocando dados entre Applets e Bancos de Dados
> >
> >
> > Prezados Javaneses,
> >
> > Há alguns anos estabeleci um modelo de desenvolvimento de sistemas
> > orientados à WEB que se baseava nos seguintes princípios:
> >
> > 1.) Interface com o usuário utilizando formulários HTML com validação em
> > JavaScript;
> > 2.) Se necessário, um pequeno Applet de apoio, utilizando LiveConnect
> > (class
> > JSObject) que integra o JavaScript com Servlets via Applets;
> > 3.) Servlets utilizando ODBC-JDBC através do free software VqServer;
> >
> > Naquela época eu evitei de programar a interface puramente em Applet
> Java
> > por problemas de performance e por não encontrar uma ferramenta de
> > desenvolvimento adequada (IDE). Todas eram muito pesadas (Jbuilder 1 e
> 3,
> > NetBeans, Forte, VisualAge etc...) e geravam applets muito pesados, além
> > de
> > serem inviáveis para se trabalhar no ambiente Windows. O pessoal da
> Fauna
> > Informática fez até um comentário que não era bom misturar muitas
> > tecnologias mas, pelas razões descritas acima, evitei de programar
> > puramente
> > em Java, no lado cliente.
> >
> > Há algumas semanas baixei o Jbuilder 4 Foundation e, ao contrário do
> Forte
> > da SUN que gera um código limpo e bonito mas que ainda é muito pesado
> para
> > operar, encontrei um produto bastante amadurecido, com uma performance
> no
> > ambiente Windows bastante suportável e me animei de desenvolver todas as
> > minhas interfaces com "Applets Pure Java". Apenas como referência,
> utilizo
> > um K6 II 350 com 96 MB para desenvolvimento de sistemas sob Windows 98.
> >
> > O motivo da minha intervenção na Lista é que já utilizo, mesmo com a
> > interface HTML com LiveConnect, uma técnica de Stream onde o usuário
> clica
> > numa Caixa de Seleção, por exemplo, e uma chave é enviada do JavaScript
> > para
> > o Applet Java via LiveConnect e este Applet se comunica com um Servlet
> no
> > servidor através da técnica ObjectOutputStream, conforme abaixo:
> >
> > // Retorna Objetos do Tipo String
> > protected void retString(HttpServletResponse hsrsp, String resultado)
> {
> >
> > ObjectOutputStream outputToApplet;
> >
> > try {
> > outputToApplet = new ObjectOutputStream(hsrsp.getOutputStream());
> > outputToApplet.writeObject(resultado);
> > outputToApplet.flush();
> > outputToApplet.close();
> > }
> > catch(IOException e) {
> > System.out.println(e.toString());
> > }
> > }
> >
> > O problema é que eu tenho implementado um servlet do modelo Single
> Thread,
> > conforme abaixo, e é estabelecido um fluxo contínuo entre o meu Applet e
> o
> > Servlet, que consulta ou atualiza o Banco de Dados, retornando um flag
> de
> > gravação bem sucedida, ou mesmo os dados do registro, no caso de
> consulta
> > ou
> > leitura do Bd.
> >
> > public class Jb001 extends HttpServlet implements SingleThreadModel
> >
> >
> > Embora este modelo funcione bem, algumas vezes ocorre um travamento no
> > Applet se muitos usuários acessarem ao mesmo tempo este recurso. Então
> vai
> > o
> > meu pedido de orientação:
> >
> > 1.) Utilizo um foco de desenvolvimento orientado para o Browser e sei
> que
> > é
> > possível criar aplicações no Servidor que trabalhem via Sockets ou RMI
> se
> > comunicando com o meu Applet, mas creio que isto implicaria em
> inicializar
> > todas estas aplicações Java no Servidor NT e gerenciar a sua execução
> > certo
> > ???
> >
> > 2.) Para evitar isto me concentrei em utilizar um Servlet Server, de
> modo
> > que todo o meu desenvolvimento Server e contato com as bases de dados
> > ocorra
> > via Servlet. É possível implementar uma outra forma de programação, via
> > Servlet, que não utilize o "SingleThreadModel" e que me garanta uma
> > comunicação MULTITHREAD entre os meus Applets e os Servlets, ou serei
> > obrigado a inicializar e gerenciar Aplicações Java rodando no servidor e
> > trabalhando com Sockets ou RMI ???
> >
> > Agradeço pelos comentários e sugestões,
> >
> > []'s
> >
> > Carlos Campos
> > Analista de Sistemas / Bolsista PCI
> > [EMAIL PROTECTED]
> > MCT / CETEM - Centro de Tecnologia Mineral
> > Fone: 0xx21 3865-7358
> > Fax : 0xx21 290-9196
> >
> >
> > ------------------------------ LISTA SOUJAVA
> ----------------------------
> > http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
> > dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> > regras da lista: http://www.soujava.org.br/regras.htm
> > para sair da lista: envie email para
> [EMAIL PROTECTED]
> >
> -------------------------------------------------------------------------
> >
> >
> >
> > ------------------------------ LISTA SOUJAVA
> ----------------------------
> > http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
> > dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> > regras da lista: http://www.soujava.org.br/regras.htm
> > para sair da lista: envie email para
> [EMAIL PROTECTED]
> >
> -------------------------------------------------------------------------
>
> ------------------------------ LISTA SOUJAVA ----------------------------
> http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
> dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> regras da lista: http://www.soujava.org.br/regras.htm
> para sair da lista: envie email para [EMAIL PROTECTED]
> -------------------------------------------------------------------------
>
>
>
> ------------------------------ LISTA SOUJAVA ----------------------------
> http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
> dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> regras da lista: http://www.soujava.org.br/regras.htm
> para sair da lista: envie email para [EMAIL PROTECTED]
> -------------------------------------------------------------------------
------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------
