Discussion :

[the-gtm]

Je reviens sur le fait que tu as une seule session factory: tu viens de rencontrer un problème, ce ne sera pas le dernier! Par exemple en faisant comme ça, impossible d'utiliser le cache de second niveau!

J'ai mesuré combien occupait une session factory en mémoire chez moi, pour 200 classes mappées: 10Mo
Demande toi si le jeu en vaut la chandelle

[olivier_44]

La solution utilisant des séquences est satisfaisante après tests.
Une autre solution consistait à implémenter son propre générateur d'id par incrément. Celui-ci devrait gérer un dictionnaire d'incréments par base (il est possible de connaitre le nom de la base à partir de la session).
J'ai préféré une solution sans code ajouté et utiliser les classes qu'implémentent l'api , ce que je voulais dans le fond, c'était trouver une solution qui ne nécessite que du paramètrage en fichiers. C'est le cas avec les séquences.

Pour répondre au dernier message:
Les tests que j'ai effectué concernant l'occupation mémoire d'une session hibernate était plutôt supérieur à 20 Mo. Le choix que l'on a effectué a été fait en connaissance de cause.

Pour les sceptiques :
Utiliser un cache de second niveau est possible avec cette solution à condition d'utiliser des identifiants UUID indépendamment de la base, hibernate propose un tel générateur.

Merci pour toutes vos participations à tous.