Fala Lenz, a interface j� est� ficando bacaninha :^) estou at� aprendendo as malandragens do drag&drop do swing.... mas vou optar por enviar um sinal via socket para o deamon, ou seja, quem ativa a interface gr�fica � a thread deamon...
assim, posso codificar a thread como Observable e fazer a interface refletir instantaneamente as mudan�as no modelo atrav�s do pr�prio MVC da API Java.. eliminando o trabalho bra�al de implementar e controlar os set, get e update... o �nico por�m � a necessidade de alocar uma porta para isso ... o que complica um pouco a instala��o.. mas pelo menos a atualiza��o � instant�nea, evitando qualquer disparidade entre a vis�o e o modelo... ainda t� em discuss�o isso por aqui.. mas acho que vai rolar um sinal via socket mesmo... valeu, Felipe Ga�cho -----Mensagem original----- De: Flavio Lenz [mailto:flavio@;lenz.eti.br] Enviada em: segunda-feira, 28 de outubro de 2002 14:15 Para: [EMAIL PROTECTED] Assunto: Re: [cejug] RMI xs Socket Voce nao pode ficar fazendo pooling no diretorio pra ver se o arquivo XML mudou ? Os containers fazem isso o tempo inteiro e o tempo nao chega a ser relevante. Provavelmente nao vai ser no seu caso. E pra sua interface ficar bacaninha, vc pode implementar um TableModel. Que tem uma estrutura de deteccao de mudancas. Dah uma olhada: http://java.sun.com/docs/books/tutorial/uiswing/components/table.html#data ----- Original Message ----- From: "Felipe Vieira Silva" <[EMAIL PROTECTED]> To: "cafeComTapioca" <[EMAIL PROTECTED]> Sent: Monday, October 28, 2002 9:09 AM Subject: [cejug] RMI xs Socket > Prezados Srs, > > estou aqui batalhando em um sistema client-server, diante da seguinte > decis�o: > > tenho dois processos no cliente: > - Uma deamon thread rodando como servi�o NT, que fica enviando arquivos ao > servidor > - Uma aplicativo Swing que serve para o usu�rio configurar quais arquivos > devem ser enviados... > > Ambos os processos compartilham a mesma base de dados, que no cliente � um > arquivo XML. > > O problema �: quando o usu�rio ativa o aplicativo de configura��o de envio, > o processo de envio j� est� rodando (fica rodando eternamente). Neste > momento, o XML com as informa��es sobre o envio deve ser compartilhado pela > vis�o da interface gr�fica e pelo processo deamon.... > > Situa��o cr�tica: > - quando o processo de envio estiver enviando um arquivo e o usu�rio tentar > mudar as informa��es sobre esse envio > - ap�s um arquivo ser enviado pela thread deamon, como refletir esse envio > na GUI? > > Como fazer para esses processos se comunicarem, evitando inconsist�ncia de > informa��es ? > > op��es que estou considerando: > - Bloquear o arquivo cada vez que a thread deamon for envi�-lo > - Criar uma comunica��o entre o processo deamon e a GUI > > no caso de criar uma comunica��o, qual a melhor op��o, considerando > desempenho, mem�ria, etc.? RMI? Sockets? File Lock? > > J� tenho uma decis�o 99% tomada, mas como esse � um caso de uso bastante > comum > entre os sistemas de troca de mensagens, resolvi jogar na lista para ver se > aparece uma opini�o nova... > > Valeu, > > Felipe Ga�cho
