São 3 computadores ligados entre eles por um switch;
Estes estão mapeados na rede Windows, ou seja, máquina 1 é a unidade E:, máquina 2 é a unidade F:\ e máquina 3 é a unidade G:;
Todas elas são desktop’s (nenhuma é servidor) sendo que a máquina 3 (G:) tem como nomenclatura “servidor”;
Não existe mais nada ligado neles, ou seja, não há Internet nem outros computadores falando com eles.
:arrow: Agora tenho a seguinte estrutura de Software: (dentro dessa rede local de computadores citada acima)
Todas estão com Windows XP e JVM instalados e na máquina 3 (G:) existe também o Postgree.
:arrow: Tenho a seguinte atividade:
Estou fazendo um sistema de cadastro de cliente que utilizará o Postgree. Esse sistema terá uma arquitetura Swing com MVC e tem que rodar nessas três máquinas usando o banco de dados Postgree que está na máquina 3 (G:). Com relação ao banco de dados, não tenho preocupação pois configuro as máquinas 1 e 2 para falarem com o banco na máquina 3 via ODBC.
:?: Então tenho a seguinte pergunta:
Agora quanto ao software (os class), como vou fazer? Preciso colocá-los em cada máquina ou somente na máquina 3 (G:) e chamo ele pela rede mesmo?
Um detalhe importante é que o MVC não pode ser quebrado, ou seja: Se uma classe do modelo mudar ele deve ser refletido em todas as máquinas, caso essas estejam com uma visão que usa essa classe do modelo alterado. [color=blue](Veja imagem abaixo em anexo)[/color]
Fico no aguardo por respostas, [color=red] muito obrigado![/color]
Não faça isto em hipótese alguma. ODBC é horrível e matará sua aplicação. Simplesmente use o modo normal de fazer isto em Java criando conexões com o bando de dados.
[quote=pedromuyala] :?: Então tenho a seguinte pergunta:
Agora quanto ao software (os class), como vou fazer? Preciso colocá-los em cada máquina ou somente na máquina 3 (G:) e chamo ele pela rede mesmo?[/quote]
OK. Mas como a máquina 1 (E:) e máquina 2 (F:) vão conseguir acessar o Postgree que está instalado na máquina 3 (G:) sem usar o ODBC?
Mesmo instalando o jar em cada máquina eles vão acessar o banco de dados que está em outra máquina?
[quote=Luca]
MVC? Explique melhor sua dúvida.
Luca[/quote]
O jar (sistema) trabalha usando MVC. É um programinha que cadastra, altera, exclui e consulta clientes.
Tente imaginar a seguinte situação:
Existe um usuário na máquina 1 (E:) que consulta um cliente X. Ele deixa a consulta lá aberta na tela (mostra visão de X).
Existe um usuário na máquina 2 (F:) que realiza alterações do mesmo cliente que está lá aparecendo na tela da máquina 1, o cliente X (altera modelo de X).
O correto é que assim que for atualizado o cliente X na máquina 2 (F:) imediatamente a visão do cliente X na máquina 1 (E:) seja notificado da alteração para reenderizar e tornar a visão consistente.
Então, mesmo colocando o jar em cada máquina (1,2 e 3) se ocorrer a situação acima o fluxo que citei vai acontecer ou não?
Se não entender, já peço desculpa antecipadamente :oops: mas eu vou tentando expor o problema até ficar visível!
É que sou iniciante em Java tenho muitas dificuldades. Agradeço a atenção Luca, obrigado por estar aqui no tópico!
[quote=pedromuyala]…Mas como a máquina 1 (E:) e máquina 2 (F:) vão conseguir acessar o Postgree que está instalado na máquina 3 (G:) sem usar o ODBC?..
Mesmo instalando o jar em cada máquina eles vão acessar o banco de dados que está em outra máquina?[/quote]
Sim, normalmente. É assim que se faz em Java. A conexão é feita direto na máquina onde está a base de dados. Veja a qualquer tutorial de JDBC. NUNCA se usa ODBC em Java.
[quote=pedromuyala]…
O jar (sistema) trabalha usando MVC. É um programinha que cadastra, altera, exclui e consulta clientes.
Tente imaginar a seguinte situação:
Existe um usuário na máquina 1 (E:) que consulta um cliente X. Ele deixa a consulta lá aberta na tela (mostra visão de X).
Existe um usuário na máquina 2 (F:) que realiza alterações do mesmo cliente que está lá aparecendo na tela da máquina 1, o cliente X (altera modelo de X).
O correto é que assim que for atualizado o cliente X na máquina 2 (F:) imediatamente a visão do cliente X na máquina 1 (E:) seja notificado da alteração para reenderizar e tornar a visão consistente.
Então, mesmo colocando o jar em cada máquina (1,2 e 3) se ocorrer a situação acima o fluxo que citei vai acontecer ou não?[/quote]
Não é bem assim que se costuma trabalhar. Há vários modos considerados “normais”. Um deles considerado otimista é deixar que os 2 clientes tentem a atualização e só se efetiva uma delas. Mas existem vários modos de trabalhar e quando você aprender mais sobre JDBC chegará a conclusão qual será o mais adequado para a sua aplicação.
O modo como descreveu é possível de ser implantado mas se 2 máquinas abrirem a mesma ficha de cadastro no modo de alteração, quando a máquina 1 receber a notificação de que os dados na base foram alterados, se perderão os dados que o usuário digitou do mesmo jeito que se perdem quando a alteração não for possível porque outro atravessou seu caminho.
Sugiro ler algum tutorial de JDBC mas quando for escrever sua aplicação considere a hipótese de usar o Hibernate (mais uma coisa para aprender)
[quote=pedromuyala]…
O jar (sistema) trabalha usando MVC. É um programinha que cadastra, altera, exclui e consulta clientes.
Tente imaginar a seguinte situação:
Existe um usuário na máquina 1 (E:) que consulta um cliente X. Ele deixa a consulta lá aberta na tela (mostra visão de X).
Existe um usuário na máquina 2 (F:) que realiza alterações do mesmo cliente que está lá aparecendo na tela da máquina 1, o cliente X (altera modelo de X).
O correto é que assim que for atualizado o cliente X na máquina 2 (F:) imediatamente a visão do cliente X na máquina 1 (E:) seja notificado da alteração para reenderizar e tornar a visão consistente.
Então, mesmo colocando o jar em cada máquina (1,2 e 3) se ocorrer a situação acima o fluxo que citei vai acontecer ou não?[/quote]
Não é bem assim que se costuma trabalhar. Há vários modos considerados “normais”. Um deles considerado otimista é deixar que os 2 clientes tentem a atualização e só se efetiva uma delas. Mas existem vários modos de trabalhar e quando você aprender mais sobre JDBC chegará a conclusão qual será o mais adequado para a sua aplicação.
O modo como descreveu é possível de ser implantado mas se 2 máquinas abrirem a mesma ficha de cadastro no modo de alteração, quando a máquina 1 receber a notificação de que os dados na base foram alterados, se perderão os dados que o usuário digitou do mesmo jeito que se perdem quando a alteração não for possível porque outro atravessou seu caminho.
Sugiro ler algum tutorial de JDBC mas quando for escrever sua aplicação considere a hipótese de usar o Hibernate (mais uma coisa para aprender)
[]s
Luca[/quote]
Ah sim concordo plenamente. Mas e se for só uma tela de consulta em uma máquina e editável em outra máquina?
Acredito que a máquina que alterar os dados deverá notificar as máquinas que tem a consulta sobre aqueles dados que eles se tornaram inconsistentes. Acredito eu, não sei!
Digo isso porque um tempo trabalhei com um banco de dados DBase (.DBF) e lembro que o programa que mostrava o banco tinha esse recurso, ou seja, se uma máquina está com a tabela em aberto e uma outra alterar aquela tabela imediatamente todas as visões NÃO-EDITÁVEIS erão avisadas da inconsistencia. Foi daí que tiri a idéia que os programas em JAVA deveriam também trabalhar nessa complexidade.
Abração Luca, valew por estar aqui! [color=red]Obrigado![/color]
[quote=pedromuyala]…e se for só uma tela de consulta em uma máquina e editável em outra máquina?
Acredito que a máquina que alterar os dados deverá notificar as máquinas que tem a consulta sobre aqueles dados que eles se tornaram inconsistentes. [/quote]
Sua tela de consulta pode ser avisada da alteração se você escrever código para isto. Com programas xBase usando tabelas .dbf isto não era automático, a gente tinha que escrever código que fazia isto. A única diferença é que com Java é relativamente mais fácil.
Ou seja, o que eu via no xBase na verdade era uma especie de thred() que de tempo em tempo atualizava a visão?
Ou o programa que mostrava o banco de dados tinha uma arquitetura MVC?
Lembro que era mais ou menos isso: Pegando a imagem anexa no primeiro post, o banco de dados (os DBF’s) estavam na máquina G: e o programa que consultava esses dbf’s (o DBU) era instalado em todas as máquinas (no caso E:\ e F:). Se E:\ estava mostrando o conteúdo de cliente.dbf e F:\ alterasse o conteúdo de cliente.dbf, imediatamente E:\ atualizava a visão que F:\ alterou. Já se o campo a ser alterado estava sendo editado em E:\ e F:\ tentasse alterar, um erro era mostrado em F:.
MVC não é isto. Estude também o que se considera MVC no Swing (que é diferente de MVC em aplicações web)
O que você diz… [color=darkblue]… Lembro que era mais ou menos isso…[/color] … não era assim. Quem atualizava precisava avisar quem estava consultando ou quem estava consultando precisava ler o registro atualizado na tabela .dbf
O que acontecia, agora falando com certeza é o seguinte: Se eu tenho a tabela Clientes.dbf aberta em várias máquinas e em uma delas eu atualizo, insiro ou excluo um registro, todas as outras máquinas imediatamente se atualizam. E o visualizador de tabelas (DBU) é instalado individualmente em cada máquina porém o dbf está sempre em uma única máquina que é de onde todas as máquinas coletam e mostram os dados dela.
Isso que eu queria implementar em programas JAVA. Mas não sei como.
Valew Luca, [color=red]abração![/color]
Não era assim. O registro só era atualizado depois de nova consulta. E o DBU fazia uma nova consulta cada vez que você rolava a tela. Caso estivesse aberta uma ficha (ou tela de um único registro), só era alterada se fosse carregada de novo (feita uma nova consulta a base). Aliás, qualquer programinha em Clipper ou Visual Foxpro que tivesse alguma serventia, tinha que fazer estas verificações se o registro não tinha sido alterado em outra máquina.
Cara em relação o .jar, faço da seguinte forma compartilho uma pasta em uma maquina ex.: \servidor\meuapp onde instalo o JVM em todas que usarão o aplicativo, então crio atalho apontando para esse caminho, com isso não preciso atualizar o .jar em cada maquina, só a do “servidor”, e o postgre fica nessa maquina “servidor” com o ip ex.: 192.168.0.1 no string de conexão uso esse ip.
Em relação ao assunto do abrir registros no DBF, programei muito tempo em clipper, e fazia da seguinte forma, quando um usuario abria o registro para alteração, nenhuma outra maquina tinha acesso ao registro, sómente quando o primeiro liberava, mas no SQL, eu nunca fiz isso, até porque não tenho motivo para ter esse controle !!!
Não era assim. O registro só era atualizado depois de nova consulta. E o DBU fazia uma nova consulta cada vez que você rolava a tela. Caso estivesse aberta uma ficha (ou tela de um único registro), só era alterada se fosse carregada de novo (feita uma nova consulta a base). Aliás, qualquer programinha em Clipper ou Visual Foxpro que tivesse alguma serventia, tinha que fazer estas verificações se o registro não tinha sido alterado em outra máquina.
O mesmo se pode fazer em Java.
[]s
Luca[/quote]
Rapaz, olha se eu tiver um tempo vou gravar um vídeo e coloco na net para você ver melhor.
Tenho certeza cara que a atualização é feita sem ninguém passar nem perto do pc.
Valew Luca, assim que conseguir eu posto!
Nem preciso ver. Na época do Clipper desenvolvi sistemas de gestão para várias empresas. E por mais que parecesse que o DBU era avisado automaticamente, isto não acontecia. Aliás o fonte do DBU era público e era um programinha bem simples.
Um dos modos mais corretos de trabalhar com DBF era fazer simplesmente o que o luisvix falou.
E a gente fazia isto em relação a TODOS os registros envolvidos na transação. Exemplo (fictício): ao alterar um registro de uma nota fiscal, todos os itens da nota eram bloqueados e ainda se bloqueava os registros das faturas, duplicatas, livros fiscais e todos os demais envolvidos na transação.
Os meus sistemas trocavam mensagens entre as estações e sempre que alguém tentava abrir um registro travado por outra, pipocava uma mensagem na tela avisando que o registro estava em uso ela tal estação que abriu. Mas isto fui eu quem fiz, nada automático do Clipper.
Ah, uma coisa importante que meus sistemas faziam era todo dia ao abrir, consistir os dados justamente para saber se alguém tinha feito alguma alteração “por fora” usando um DBU da vida. Caso afirmativo, soltava alarmes e minha responsabilidade ficava resguardada.
Olá fantomas, bom dia!
Obrigado por ajudar neste tópico também!
[quote=fantomas]Segue uma imagem sobre uma sugestão de como resolver este problema.
flws
[/quote]
Parece ser a solução ideal mesmo. Vou precisar estudar sobre JMS, DBMS, e outras dúvidas no geral!
Sugere algum artigo, livro,…?
Um abração, [color=red]Obrigado![/color]
Então eu também fazia dessa forma com os programas em Clipper. Só que na conexão com o banco nem era necessário configurar IP nem nada. Criava o aruivo dentro da pasta onde estava o programa e usava “USE CLIENTES”, já era. Mas como eu sei que fazia esses programas com estruturas do tipo “qualquer jeito”, eu quero mudar isso agora que estou em Java e fazer de uma forma que a comunidade entenda sem muito sacrifício.
Um abração, obrigado por estar aqui no tópico![color=red]Valew![/color]
Nem preciso ver. Na época do Clipper desenvolvi sistemas de gestão para várias empresas. E por mais que parecesse que o DBU era avisado automaticamente, isto não acontecia. Aliás o fonte do DBU era público e era um programinha bem simples.
Um dos modos mais corretos de trabalhar com DBF era fazer simplesmente o que o luisvix falou.
E a gente fazia isto em relação a TODOS os registros envolvidos na transação. Exemplo (fictício): ao alterar um registro de uma nota fiscal, todos os itens da nota eram bloqueados e ainda se bloqueava os registros das faturas, duplicatas, livros fiscais e todos os demais envolvidos na transação.
Os meus sistemas trocavam mensagens entre as estações e sempre que alguém tentava abrir um registro travado por outra, pipocava uma mensagem na tela avisando que o registro estava em uso ela tal estação que abriu. Mas isto fui eu quem fiz, nada automático do Clipper.
Ah, uma coisa importante que meus sistemas faziam era todo dia ao abrir, consistir os dados justamente para saber se alguém tinha feito alguma alteração “por fora” usando um DBU da vida. Caso afirmativo, soltava alarmes e minha responsabilidade ficava resguardada.
[]s
Luca[/quote]
Mas Luca, porque isso acontece aqui então cara? Tem uma explicação?
Porque cara eu também desenvolvia os sistemas nessa hierarquia que você falou. Pegou até um exemplo bom da nota fiscal.
Mas tenho absoluta certeza que quando os 2 DBU’s em máuinas distintas tem o mesmo DBF aberto e algo for alterado em uma das máuinas imediatamente a outra se atualiza sem eu precisar encostar na outra.
Obrigado Lucão por estar ajudando, [color=red]valew mesmo![/color]
