regarde la doc, et comprend que la méthode values() ne synchronise pas les objets qui y sont contenu, seulement le conteneur. De plus les valeurs associées aux clés peuvent être nulles temporairement avec le comportement optimiste (et il n'est pas interdit non plus de stocker des valeurs nulles si ta base de données ne renforce pas cette contrainte, sachant qu'il y a aussi des filtres sur les espaces, ou similaires, des valeurs non convertibles si le type de binding sur tes champs de donénes ne corespond pas exactement au type de ta base SQL, qui est aussi sans doûte manipulée séparément si tu n'a pas pris soin de faire une transaction pour avoir une vue stable: attention aux lignes effacées avec DELETE dans d'autres sessions, Hibernate ne résoud pas tous les problèmes de gestion des sessions et possède lui aussi un comportement optimiste).
Ce n'est pas parceque ta HashTable est synchronisée que tu dois t'attendre à ce que les valeurs qu'il contient soient non nulles. (Note bien: HashTable n'est pas une Collection, seule HashMap en est une, mais n'est pas du tout synchronisée).
Exempel de problème: hasNext() et next() sont peut-être synchronisés, mais si la HshTable n'est pas elle-même verrouillée, il y a la possibilité que le retour de hasNext() autoise un autre thread à modifier le contenu de la HashTable avant que tu obtienne le droit de lire l'élément suivant de la liste. HashTable en particulier doit parcourir les listes de hashbuckets (qui sont "vivantes" ), en utilisant un énumérateur avec plusieurs variables complexes.
Mais je serais toi je me poserais plutôt des questions d'abord sur les bindings de type entre les colonnes SQL et tes attributs d'objets en Java...
