Discussion :

[ebaynaud]

Bonjour,

Je rencontre un problème dans la mise en oeuvre du pattern J2EE / EJB (http://knotty.developpez.com/j2ee/ejb/). Mon système de cache contient une quantité importante de données. Certaines requêtes à ma servlet prennent des paramètres, pour un filtrage des données à retourner.

Mon problème est que ces opérations de filtrage sont à mon avis couteuses et ainsi je pense qu'il serait préférable qu'elles se fassent dans le container EJB pour résister à la charge (qui peut être très importante), non ? Quelle est la meilleure solution à adopter ? Est-t-il possible de modifier le pattern pour que le cache soit dans l'EJB container et si oui comment ? Suis-je clair ? Avez-vous un autre design à proposer ?

[bmoussaud]

Je te répondrai par une autre question:
pourquoi as-tu besoin d'un mécanisme de cache ?

[ebaynaud]

Pour supporter une grosse montée en charge ! Si j'interroge ma base et que je réalise les traitements d'adaptation des données (nombreux et lourds) à chaque requête de l'utilisateur, je pense que mon système va exploser !

[ebaynaud]

Bon, j'ai changé d'avis.

J'utilise maintenant un pool de SessionBean stateless, et je crée mon cache à la création de mon bean (dans ejbCreate) ((en fait, je remplis une variable d'instance)). J'ai un problème pour la mise à jour du cache, par contre. Les timers que je pensais utiliser ne concernent qu'une seule instance de bean dans le cas des SessionBean stateless et pas toutes les instances. Comment puis-je mettre à jour mon cache pour toutes mes instances de bean dans ce cas, une idée ?

[ebaynaud]

Plus simplement :

Comment mettre à jour une variable accessible par toutes les instances de bean Session sans état ?

[bmoussaud]

Plus simplement :

Comment mettre à jour une variable accessible par toutes les instances de bean Session sans état ?

* une variable de type 'static' si tu es mono serveur
* un entity bean sur tu es sur un cluster.

[bmoussaud]

Pour supporter une grosse montée en charge ! Si j'interroge ma base et que je réalise les traitements d'adaptation des données (nombreux et lourds) à chaque requête de l'utilisateur, je pense que mon système va exploser !

En effet, tu penses. Tu es donc dans une optimisation 'a priori'. C'est souvent dangereux. Je fais régulierement des missions de tuning et de profiling d'applications J2EE. Régulierement les points de blocage d'une application ne sont pas ceux identifiés a priori, pire ce genre d'optimisation peuvent être parfois catastrophique

Ensuite admettons que ce point fasse exploser ton application (je reprend ta formulation): la solution de cache est-elle la meilleure ? une vue dans la base de données n'est-elle pas une autre solution ?

Ce lien (en anglais désolé) expose les dangers du 'caching': Improper caching
http://blog.xebia.com/2007/03/26/eja...roper-caching/