Dúvida JDBC: PreparedStatement e Connection

Bom dia a todos.
Estou fazendo um programa que basicamente recebe dados via socket de vários aparelhos e grava estas informações num banco de dados (MySql).

Para cada equipamento que conecta no programa, uma nova thread é criada que fica recebendo os dados até que seja finalizada a comunicação.

A minha dúvida é a seguinte: Se eu possuir APENAS UM Connection para todas as Threads (no servidor) e um PreparedStatement na execução das threads, na execução do método executeUpdate() poderá haver problema de concorrência?

A classe PreparedStatement deve utilizar o objeto Connection para a execução do método para persistir os dados no banco.

Qual a melhor solução para este problema? Criar um novo Connection para cada Thread? Criar um método no servidor que seja sincronizado?

Desculpem-me se não ficou muito claro. O programa esta funcionando, só estou com receio de que este problema se confirme e que eu venha a ter problemas futuros.
Desde já agradeço. :slight_smile:

Bom dia

Bom se eu entendi sua pergunta, você esta com medo da sua unica connection ficar sobrecarregada com suas threads e ter problemas de concorrência, com relação a isso, problemas de concorrência você não vai ter, porque seria como se em uma unica conexão você estivesse realizando varias operações sql, agora se o caso fosse de objetos persistidos, ai sim você teria que sincronizar seu objeto ou métdoo, porque as thread iriam trabalhar em cima do mesmo objeto.

Bom eu recomendo você a trabalhar com pool de conexões, como sua aplicação é desktop e você não tem um conteiner para fazer o pool via JNDI, utilize a API da Apache chamada de DBCP, com ela você pode fazer pool de conexões, que no seu caso é muito recomendado.

http://commons.apache.org/dbcp/

Falou.

Uma outra solucao q seria interessante eh a utilizacao de JMS ou pelo menos, do conceito por traz disso.

Os clientes mandariam a requisicao e vc as armazenaria numa fila (alguma queue). Cada thread adicionaria seu conteudo la.

e o processo que se conecta com o banco obteria os conteudos armazenados e os salvaria no banco um por vez. Sem problemas de concorrencia, sem abrir varias conexoes… tudo bonito

Ai vc comeca a ver as coisas feias: se a aplicacao cair, tudo q estava na queue eh perdido. Entao, depende do grau de seguranca que vc quer na sua aplicacao. serializar a fila de tempos em tempos tb ajuda a evitar perdas, mas diminui a velocidade do processo. Enfim, depende muito da necessidade.

pois é,
na primeira versão eu implementei uma queue, o problema é que alguns dados não podem ser perdidos. Eu cheguei na mesma conclusão de segurança que tu chegou. É meio ruim, pois o hardware que esta comunicando com o meu programa é meio limitado, e não pode receber as confirmações separadas do envio.

é interessante a idéia do pool de conexões, nunca implementei um, vou dar uma olhada.

eu andei pensando, se eu fizer métodos syncronized para gerir as queries com o banco, isto não ajuda a resolver o problema?

agradeço a atenção de vocês ai.