Estou com a seguinte duvida:
Tenho uma aplicação que fica verificando em uma Thread se um determinado dado foi atualizado no banco de dados, caso ocorra alguma atualização o comportamento da ferramenta muda por exemplo. Mas gostaria de saber se realmente é correto utilizar Thread para este tipo de problema. E se Observer poderia ser utilizado.
[]'s
DESCULPE COLOQUEI NO INDICE ERRADO. POSTEI EM JAVA AVANÇADO.
Dá para utilizar ambos. Mas eu sempre prefiro fazer isso via o meu próprio thread. Acho que fica mais bonito, organizado e o mais importante é que te dá controle total sobre a coisa.
Se você quer realizar uma tarefa de tempos em tempos, acho que o mais fácil é utilizar a classe javax.swing.Timer. Mas já que você já fez com threads, tudo bem 
O código que faz a alteração no banco de dados deveria se registrar em um objerver que é quem tem a thread que fica acessando o banco de dados pra ver se o valor mudou.
A thread continua lá, mas ela vai ser encapsulada pelo observer e quem usa o observer não precisa saber que ele está usando threads pra fazer isso.
Via de regra, se o observer for um recurso suportado pelo seu banco de dados, prefira-o. Geralmente é melhor usar um observer do que fazer pooling (ou seja, deixar uma thread o tempo todo perguntando “O dado mudou?”).
Agora, a maior parte das implementações JDBC padrão não suporta um observer. Nesse caso, você terá mesmo que criar uma thread de pooling, e então usar o observer como mecanismo de comunicação dessa thread com o mundo exterior.
Quem usa o observer precisa sim saber se o evento do observer vem ou não em outras threads. Isso pode ter um impacto significativo na arquitetura do sistema, caso esse observer acesse recursos compartilhados. O que você pode fazer é criar uma fila de mensagens na thread da sua aplicação e fazer com que a thread que vigie o banco só coloque uma mensagem lá. Nesse caso, somente a classe da fila teria que ser thread-safe, o que reduz consideralvemente os problemas de concorrência, embora também reduza um pouco o paralelismo. Essa é a estratégia usada no Swing.
Assim ele vai ter que fazer pull no banco e depois pull nessa fila, o que vai complicar ainda mais o design da coisa. Se registrar num observer que manda notificações assíncronas é muito mais simples, pois o listener dele simplesmente receberia a notificação e mandaria o código alterar a interface com um invokeLater, sem ter que puxar os dados de dois lugares diferentes.
Acho que você não leu direito o que escrevi:
Fazer um invokeLater é exatamente fazer um pull nessa fila. Só que a fila é mantida pelo Swing.
O que eu estava falando era de usar exatamente a mesma estratégia para o resto da aplicação, caso o seu observer provoque mais do que simples atualizações de tela.
Vocês teriam algum material para me aprofundar mais sobre Observer?
[]'s