Atualizações de um banco de dados

Acredito que tenha como… ao meu ver essa proposta de “avisar sobre qualquer atualização” me parece ser a melhor opção. Agora como fazer… uma alternativa é usar socket , a aplicação cliente fica escutando uma porta, e a servidor avisa nessa porta das atualizações… (tem mais complexidade por ai, talvez tenha uma forma melhor para fazer).

Agora se você está usando web, vc pode usar ajax e o mesmo receber as atualizações a atualizar a tela. Lembre-se que ainda tem o risco de um pequeno delay de atualização… Nessa opção vc teria a sessão do usuário ativa ad eterno…

Olá Baroni,

Vc poderia acrescentar umas informações pra ajudar a responder?

“Client side” seria o que: Web/Desktop?
Qual a ordem de grandeza do nro de clientes? 10, 100, 1000…
Qual a características/formato dessa da informação do “Server Side”? Mais precisamente: msgs curtas, documentos?
Como as informações são atualizadas no “Server Side”? Com qual frequência? Qual volume?

Att.,
Renato

Renato, segue abaixo uma descrição mais clara do sistema:

Houve um concurso onde os melhores colocados escolhem para qual cidade querem ir. A escolha é feita verbalmente no dia marcado. A banca julgadora chama o candidato e ele diz qual cidade deseja. Nesse ponto entra o sistema. Ao ouvir qual cidade o candidato escolheu o administrador lança no “Server Side” que o candidato “X” escolheu a cidade “Y”, ficando essa cidade impossibilitada de ser escolhida por outro candidato.

O “Client Side” fica com o trabalho de mostrar para os candidatos que ainda não escolheram as cidades que continuam disponíveis.

Se houver um delay muito grande no recebimento dessas informações pode haver problemas, como, por exemplo, um candidato tentar escolher uma cidade anteriormente escolhida, mas que ele não sabia pelo sistema estar com delay. Estou receoso também pois um excesso no tráfego de dados pode “emudecer” o sistema causando um grande problema.

Eu terei algo em torno de 600 clientes conectados simultaneamente. O problema é que eles estarão no mesmo local (na mesma rede) pois todos estarão aguardando para dizer qual cidade desejam, portanto a quantidade de fluxo de dados é crítica.

O “Server Side”, até onde eu pensei, faz apenas execuções de Queries SQL para marcar no banco a cidade como indisponível. A freqüência depende muito da velocidade com que os candidatos responderão à banca julgadora.

Há a preferencia de que o “Client Side” seja desktop.

Interessante… Eu acho o seguinte: A solução ‘pull’ é mais adequada tecnicamente para esse problema, porém(na minha opinião) um tanto mais complexa do que só fazer refresh. A solução push(refresh), pelo cenário que vc descreve, me parece OK também, no fundo acaba dependendo mais da sua infra… não é a mais adequada mas sabe como é, acho que aí depende mesmo é do tempo que vc teria pra fazer. Uma outra opção de implementação na abordagem pull, além da que o leonardocregis sugeriu, seria usar uma solução com um cache compartilhado(terracota, memcached, treecache) para propagar as alterações. O que não dispensaria persistir isso em BD também.

Baroni:

Renato, segue abaixo uma descrição mais clara do sistema:

Houve um concurso onde os melhores colocados escolhem para qual cidade querem ir. A escolha é feita verbalmente no dia marcado. A banca julgadora chama o candidato e ele diz qual cidade deseja. Nesse ponto entra o sistema. Ao ouvir qual cidade o candidato escolheu o administrador lança no “Server Side” que o candidato “X” escolheu a cidade “Y”, ficando essa cidade impossibilitada de ser escolhida por outro candidato.

O “Client Side” fica com o trabalho de mostrar para os candidatos que ainda não escolheram as cidades que continuam disponíveis.

Se houver um delay muito grande no recebimento dessas informações pode haver problemas, como, por exemplo, um candidato tentar escolher uma cidade anteriormente escolhida, mas que ele não sabia pelo sistema estar com delay. Estou receoso também pois um excesso no tráfego de dados pode “emudecer” o sistema causando um grande problema.

Eu terei algo em torno de 600 clientes conectados simultaneamente. O problema é que eles estarão no mesmo local (na mesma rede) pois todos estarão aguardando para dizer qual cidade desejam, portanto a quantidade de fluxo de dados é crítica.

O “Server Side”, até onde eu pensei, faz apenas execuções de Queries SQL para marcar no banco a cidade como indisponível. A freqüência depende muito da velocidade com que os candidatos responderão à banca julgadora.

Há a preferencia de que o “Client Side” seja desktop.

Simples, basta fazer com que uma atualizacao no server gere um evento que notifica os clientes, pode fazer isso com JMS por exemplo, ou athe WEB, com DWR jah da athe para fazer com que o servidor chame os clientes, sobre o trafego e ficar lento a atualizacao e bla bla bla, simples… quando um usuario selecionar uma opcao, voce manda para o servidor a mensagem, se jah tiver sido escolhida, voce simplesmente retorna uma mensagem para desfazer a operacao, eh basicamente um mecanismo de Lock, voce pede pro servidor um recurso, nao ha como evitar que um mesmo recurso seja pedido ao mesmo tempo em duas maquinas diferentes, mas logicamente uma chegara primeiro no servidor, a que chegar primeiro vc libera e a segunda mensagem vc pede pra fazer rollback da acao, sussa sussa.

Flws!