Utilizando o java desktop em rede

Sobre gravacao(insert), alteracao(update), apagar(delete) e consultas(select)…Tudo isso vai da modelagem, se foi bem feita naum se preocupe o proprio banco cuida disso pra vc.
Sistemas em rede, tbm depende de como foi modelado.

eu ja fiz de 2 maneiras.

1 - o mesmo client para todas as maquinas, por exemplo, um mesmo arquivo.jar fica no servidor e as estacoes de rede mapeiam o servidor buscando o mesmo arquivo.jar, todos os clients buscam o BD.
2 - um arquivo client para cada maquina.

O que importa na verdade eh a conexao com o banco para poder fazer seus inserts, updates, deletes e selects …Entaum, a rede tanto faz pq os clients sempre vaum buscar o msm bd.

t+ e boa sorte.

Ola fernandopaiva, muito obrigado pelo retorno.
Comecei a desenvolver este sistema no trabalho final do meu curso tecnico, por isso fiz uma modelagem bem feita, toda na 5ª forma normal, não ha repetiçao de dados nas tabelas, esta bem modelada. Porem antes nao tinha intençao de coloca-lo em rede, entao fiquei com receio de dar algo de errado na hora da comunicaçao de varias maquinas com o banco. Bom, a respeito das duas opçoes de sistemas em rede, qual voce acha melhor, que da menos problelma?. Inicialmente queria fazer um client e um servidor, porem se o outro metodo de deixar um jar e compartilhar com os demais for mais tranquilo, irei optar por ele. No caso nesse segundo metodo, pode haver algum conflito no banco?, ou algum conflito de varias maquinas acessarem o mesmo arquivo?

Outra duvida, no caso, com uma modelagem bem feita eu teria mesmo assim que tratar os erros que podem ocorrer quando duas maquinas tentarem acessar o mesmo arquivo?, desculpa estar fazendo tantas perguntas, é pq ja estou meio atrasado com este projeto e ate agora nao consegui uma saida, entende.

Basta colocar o banco em apenas uma das máquinas, que será o servidor e tomar cuidado com a abertura e fechamento de sessões e transações com o banco. Você está usando Hibernate ou está usando SQL na unha?

Abriu a conexão, feche-a.
Inicie a transação e depois use o commit (ou rollback nos erros).
É sempre bom pesquisar sobre como implementar logs de transação.

Ola oliver, estou usando sql na unha mesmo, estou emperrado neste sistema, por isso nao consigo aprender coisas novas, estou so esperando termina-lo para começar a estudar mais coisas. A respeito do comit e rolback, cara, sou novo no java, nem sei o que é isso.
Bom, fazer uma pergunta, se eu pegar o sistema e fizer normalmente sem se preocupar com a parte de rede, pode haver algum problema?, sendo que varias maquinas vao acessa-lo, como o colega anterior falou, tem dois meios de compartilhar, um é colocando o banco em um servidor e fazendo softwares clientes, outro meio é compartilhar o mesmo arquivo pela rede. Qual o melhor meio?

A respeito das conexoes, sempre que abro a conexao, depois de utilizar os recursos, imeditamente eu fecho, sem exceçoes.
Obrigado

Quando você precisa gravar em duas tabelas numa só tacada. Todo banco de dados aceita estes comandos, é bom ler sobre isso.

Até 10 máquinas sempre usei assim:
Servidor do banco (máquina dedicada) <------> Máquinas clientes (cada uma com uma cópia do programa)

Quando o número de máquinas torna-se maior, uma dor de cabeça que vc poderá ter é quanto à atualização do Software, pois demandará muito tempo de mão de obra ficar copiando em cada máquina o seu software. Quando vc tiver um tempo (no futuro) estude sobre isso.

Na verdade, se vc deixar o seu .jar no servidor e as estacoes mapear uma unidade dele eh soh adicionar um atalho para a aplicacao q esta no servidor.

veja.

estacao -> mapeiaservidor de app (no servidor esta instalado o banco)
estacao tem atalho para o .jar q esta no servidor -> se precisar atualizar o software basta fazer isso soh no servidor pq nas estacoes ja vai estar atualizado, pq elas buscam apenas o atalho.

sobre o banco, como eu disse, se estiver bem modelado ele faz todo o trabalho sujo.

t+ e boa sorte

Não é bem assim …

Você precisa saber quais níveis de isolamento de transação seu banco de dados suporta. Sabendo isso, é preciso configurar o nível desejado no JDBC:

Connection conn = getConnection();
conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);

Com READ_COMMITED você já garante que apenas 1 transação altera uma tabela por vez. Além disso, uma consulta vai retornar apenas registros que sofreram COMMIT. Isso é o suficiente para a maioria das aplicações.

O entendimento de transações é fundamental para quem deseja construir sistemas com bancos de dados.

Eu não conhecia essa: muito interessante.