Oi, Marcelo,

Bom, j� que voc� j� est� ciente do problema da serializa��o, acho que a
melhor alternativa � a seguinte:
fa�a uma interface de listener, que recebe um evento do core (uma chamada de
m�todo) que o comando terminou de executar. Fa�a com que a sua servlet
implemente essa interface. No m�todo, vamos cham�-lo de
commandCompleted(Command), voc� seta um atributo da servlet, lembrando-se de
sincronizar o acesso a ele. No m�todo doGet() ou doPost() da sua servlet, vc
entra em loop infinito, chamando Thread.currentThread().yield() para fazer a
espera o menos custosa poss�vel. A condi��o de sa�da do loop � a vari�vel
sincronizada ter sido setada.
Para que o pr�prio comando devolva a resposta para o browser, vc pode passar
para o construtor do comando (supondo que o comando seja constru�do e
destru�do a cada execu��o), o HttpServletResponse.getOutputStream(). Dessa
forma, voc� n�o amarra os comandos ao uso de servlets (ele recebe um
OutputStream qualquer), e evita de misturar c�digo de output na servlet
principal.

Em resumo, voc� faz com que a servlet espere o "core" terminar de processar
o comando (da forma ruim, pois ela tem que ficar fazendo pooling, sen�o o
m�todo doGet/doPost retorna e o container acha que a servlet terminou de
processar).

Acho isso deve funcionar.

Abra�os,

Renato.


> -----Mensagem original-----
> De: Marcelo Magno [mailto:mmagno@;blumar.com.br]
> Enviada em: Wednesday, November 06, 2002 3:50 PM
> Para: [EMAIL PROTECTED]
> Assunto: RE: [enterprise-list] Foward de fluxo de execucao de um servlet
>
>
>       Salve Renato... Entendi o que voce quiz dizer...
>
>       O problema � que infelizente eu nao tenho como tirar a
> serializacao desses comandos ao core agora pois eu estou tentando
> provar que um algoritmo de concorrencia funciona. O q acontece �
> que eu fiz uma implementa��o baseada em um protocolo de comandos
> ao core, e esses comandos sao tao "Atomicos", que sua execu��o
> ser� extremamente r�pida...
>
>       Eu continuo com o paralelismo na quantidade de clientes,
> mas nao posso na execu��o dos comandos (pelo menos nao nesse
> momento - pra mim cada comando tem que ser executado no core
> atomicamente).
>
>       To vendo que nao vou ter muito mesmo como fugir de colocar
> o servlet nesse ponto para esperar um poukinho colocando ele para
> durmir ou coisa parecida, enquanto eu nao devolvo a resposta. Mas
> o legal � que se eu conseguisse passar a frente o contexto do
> servlet, ele vai estar esperando, mas pelo menos lah na frente na
> execucao do comando dentro do core eu nao precisaria devolve-lo
> para ele acordar para depois retornar a resposta.
>
>       Num futuro breve, estarei implementando dessa outra forma,
> alguem envia, alguem busca, pois pelo que tenho visto assim
> conseguirei aumentar ainda mais o paralelistmo de minha solucao.
>
>       Grato pela for�a.
>       Marcelo Magno
>
>


---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para: 
[EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]

Responder a