Discussion :

[mahoney]

Bonjour,

je suis en train de développer une série de WebServices en REST/JSON via Jersey. Ces WS sont censés effectuer de simples actions CRUD en interagissant avec une base MySQL via JDBC.

Actuellement, ces services sont fonctionnels et les tests unitaires passent sans souci, mais en effectuant quelques recherches en terme de sécurité et performances, je me rends compte que mon architecture doit être améliorée, sur la gestion des connexions à MySQL.
J'ai donc dégagé plusieurs pistes :

1- chaque WS va instancier une connexion, un preparedStatement et un resultSet pour envoyer la requête:
cette solution me parait un peu "bourrin", et surtout je ne connais pas le comportement du système en cas de centaines d'appels au WS par minute : surcharge du serveur? limite de connexions?

2- la connexion est instanciée dans un singleton, et chaque WS va récupérer un preparedStatement et un resultSet pour envoyer la requête :
ça règle le problème des connexions intempestives, mais que se passe-t-il si plusieurs appels aux WS ont lieu en même temps? une file d'attente se crée, et les appels vont tranquillement consommer la connexion 1 par 1?

3- utiliser un pool de connexion :
là c'est un peu + obscure, apparemment je pourrais utiliser commons-dbcp, qui en théorie réglerait toutes les problématiques sur la gestion des connexions.

Etant plus ou moins novice dans les best practices de JDBC, j'ai besoin d'un avis éclairé sur ces 3 architectures : laquelle serait la plus adaptée à mon besoin (qui est de consommer des WS simples, de façon répétée et avec des appels concurrents) tout en restant relativement simple, générique et efficace?

[fr1man]

On ne partage pas une connexion entre plusieurs threads, donc oublie cette solution.
La bonne solution est d'utiliser un pool de thread et de bien penser à faire un close sur ta connexion et tes statements pour rendre la connexion au pool.

EDIT: je voulais dire un pool de connexions pas de threads

[mahoney]

Merci pour la réponse, je vais regarder du côté du pooling alors