Alors, je vais essayé d'être clair, sans pour autant expliquer tout mon projet, chose qui serait un peu trop complexe.
En gros, je cherche à rendre mon appli multilingue.
Mes contraintes sont les suivantes :
- Environnement Jsp/Servlets
- Libellés récupérés en base de données
 
Après étude, je dirais que 2 procédés s'offrent à moi :
1) soit je stocke en session, dans un objet dédié, l'ensemble des libellés correspondant au langage d'un utilisateur
2) soit je récupère individuellement chaque libellé, lorsque le besoin s'en fait sentir chaque libellé en base de données  
 
Il faut savoir que mon appli est une appli interprétant des scripts, et que le plus souvant, seuls environ 10% des libellés stockés en base seront utilisés (privilégie la solution 2)
Le nombre de libellés utilisés est relativement restreint (disons maxi ~100)
Pour l'intégration, la solution la + simple est la 1ère.
Vous trouvez ça choquant de stocker pour chaque utilisateur, une HashMap contenant au plus 100 String ?

El_gringo > non.
 
tu fais une Map par langue qui sera globale à tous les utilisateurs. cette map sera backée par la BDD, et ira chercher les données à la demande dans la BDD (avec un cache, biensûr). tu pourras stocker une référence à la bonne map dans chaque session utilisateur, c'est pas le pb, ça te coutera 4 octets par session.

Tu peux te risquer à utiliser Struts, dont un des tenants est de faciliter les application multilingues...
 
Mais +1 pour la solution de Nicolas, simple, facile et efficace.

 
"Non", c'est pas ma dernière question ("vous trouvez choquant..." ) ?
 
Ouais, ton système me plait. En gros, c'est faire une sorte de ResourceBundle, mais backé par la bd au lieu de l'être par un fichier.

sircam > ça peut devenir complexe dans la map (si un lock de tout le cache n'est pas envisageable pour cause de contention et qu'un lock fin doit être trouvé), mais le gros avantage, c'est que la complexité est "contenue" à un seul point.
 
et surtout le développement peut se faire de manière très incrémentale : on commence par une simple hashmap synchronizée qui charge toute la table dans ce qui deviendra le cache, on fait un chargement "à la demande" du cache, et si le cache est un point de contention, on pinaille sur un locking fin (peut-être même en plusiseurs étapes en començant par un simple reader/writer, puis en rafinant jusqu'à avoir la perf).

 
On va pas mettre Struts à toutes les sauces non plus. C'est peut être très bien ce truc, mais là, mon appli existe déja, et je vais pas la migrer vers Struts pour un bête ajout d'un système de traductions...

en fait, ne fait même pas une map, fait une classe à toi. c'est nul d'utiliser une map pour ça.

Ben, y aura bien une Map sous-jacente qd même. Puisque je n'irait pas chercher mes libellés en base de données chaque fois que c'est nécessaire, il faut bien que je stocke une correspondance identifiant-libellé, pour ça, quoi de mieux qu'une Map <String,String> !?

ouioui le cache sera une map, je parle de l'extérieur. le machin dans lequel tu iras chercher tes string depuis la session n'a pas besoin d'être une map, juste une classe avec une méthode getLocalizedString(String id).

Ouais ouais, bien sur.
Merci pr les idées en tt cas.

de rien, j'adore pinailler sur ces sujets.

ça détend, avant de remttre le nez dans Maven ! (comment ça je suis sadique !?)

t'as pas été voir mon dernier post sur ce sujet ...

sinon pas besoin de mettre quoi que ce soit en session, ca ne sert à rien, c'est même plutot nefaste si tu as beaucoup d'utilisateurs simultanés...
et pour un cache, LinkedHashMap est une excellente implémentation de Map, si on a besoin de maitriser la taille du cache.

de toute façon si j'ai bien compris le problème la synchronization on s'en fout, on ira jamais écrire dans la map, juste faire des lectures, non ?

Reg > si c'est juste un cache, non, les données qu'on va chercher pour la première fois dans la base, il faut les insérer dans le cache.

Ne vaut-il pas mieux dès lors aller chercher les données dans la DB et remplir d'office le cache, p.e. au démarrage de l'application, sans accès concurrent, pour ensuite ne travailler qu'en lecture seule ? On économiserait les pénalités liées à un accès sérialisé.

sircam > oui, s'il a vraiment peu de données par rapport au reste c'est évident. surtout qu'il ne doit pas être loin du seuil où il est très économique de tirer toutes les lignes d'un coup de la BDD.
 
comme toujours : sa conception concrète de la chose dérivera naturellement de ses contraintes techniques, sans qu'il ai vraiment de choix à faire lui-même, tout les choix résultent plus ou moins de diktats techniques. Par contre, bien wrapper proprement pour que toute la décision soit contenue à un seul point et que s'il y a remise en cause (par exemple, par la croissance naturelle de l'application qui augmenterait le nombre de chaines à traduire et changerait les compromis), ça impacte un minimum de code utilisateur de ça.
 
Concernant le contenu de ce truc, on a pas le projet complet (et son salaire) pour faire les choix à sa place

 
 
Voilà, El Gringo, tu as maitenant qq pistes à suivre.

J'avais déja des pistes à suivre. Maintenant, j'ai d'autres avis que le mien, nuance.
Merci à tous pour ça d'ailleurs.