Hibernate version: 3
MySQL 5.0.12
Driver jdbc 3.1.10


Bonjour,

Nous utilisons hibernate 3 pour un projet Java, avec Tomcat, Struts et MySQL 5.0.12 (qui est en beta). On utilise un pool dbcp de tomcat pour hibernate.

Lors des tests de montée en charge nous avons détecté un problème. Pour charger un objet de la base on utilise session.get(). Cette méthode est supposée ne renvoyer null que si la ligne n'existe pas dans la base. Or de temps en temps session.get() nous retourne null alors que l'objet existe en base. On est sûr qu'il exisye puisque tous les threads des tests de montée en charge appelle sesson.get() avec le même id et la plupart arrivent à charger l'objet.

Si on fait un boucle sur le chargement jusqu'à ce qu'il arrive à charger la ligne ça passe, mais on trouve ça bizarre quand même...

Si c'était MySQL qui n'arrivait plus à suivre je pense qu'on aurait des exceptions du type "too many connections", "try restarting transaction", "pool exhausted", etc. On a aussi des exceptions de ce type mais c'est "normal".

Donc ma question: est-ce que session.get() ne devrait pas retourner null si et seulement si l'objet n'existe pas dans la base ?

Pensez-vous que le problème vienne pluôt du fait que MySQL 5 est encore en beta, ou plutôt d'hibernate ou de notre mapping ?

Merci d'avance.

Cela me semble être l'hypothèse de travail la plus raisonnable.

Une question: travaillez-vous avec des transactions? Avec quel niveau d'isolation? Comment fonctionne MySQL 5.0.12 dans ce domaine?

J'aurais tendance à penser que les réponses à vos questions sont à chercher par là plutôt que dans Hibernate.

Il serait bien sûr intéressant de tracer ce que fait Hibernate et/ou la BD, mais il est à craindre que cela influencerait trop les opérations en cours.

Cela dit, je ne suis pas un spécialiste de BD et mes commentaires sont donc à considérer avec prudence :-).

Erik

Pouvez-vous poster le code qui vous permet de simuler cette montée en charge.
Outre l'intérêt d'avoir un exemple d'utilisation d'hibernate, cela nous permettra peut-être aussi d'avoir des idées.
Merci.

Oui nous travaillons avec des transactions. Le niveau par défaut dans MySQL est SERIALIZATION mais on obtient la même chose avec READ COMMITTED.


un extrait du code :




Petite précision comique : même avec une grosse montée en charge ça fonctionne très bien avec un pool de 1 connexion...

Pour les tests de montée en charge on utilise Jmeter.