Donc
tu as teste uniquement BMP ? Et jamais CMP 2.0 ?
Oui, c'est parfait sur le plan intellectuel, ca résout pas mal de choses, mais :
Avec les CMP 2.0 on peut faire de très belles choses, mais entre un design objet et un design relationnel, il y a une très grande différence d'impédance. C'est vrai qu'on peut faire des relations 1-N, M-N, ... avec les Container Managed Relationships(CMR).
Mais aujourd'hui, on souffre aujourd'hui d'un design des tables privilégiant les performances qui ne s'adapte pas du tout au modèle objet.
Exemple type : c'est pas parce qu'on a une relation M..-N qu'on peut se projeter directement d'une table sur une autre.
Donc la solution se ferait obligatoirement au travers de BMP, et dans de rares cas de CMP, car il faut resynthétiser une information.
On a une application serveur qui tourne en tâche de fond et un front-end web. Le serveur génère des données en masse et ces données doivent très vite être insérées en base (d'où le design que j'évoquais). C'est vrai qu'avec des local entity on pouvait faire ca côté serveur, car on n'aurait pas eu le
temps d'invocation à distance et en plus on tombait dans le cas où les CMR sont disponibles. Par contre, le frontal web aurait du lui faire des invocations à distance (JVM séparée), ce qui nous aurait conduit à
développer des EJB sessions stateless pour les vues. Et vue la tête des vues, on ne coupait pas au SQL dans les EJB sessions, ne serait que
pour réaliser les queries.
Aujourd'hui on a défini et implanté une architecture MVC et 2 types de cache : un pour le côté serveur, un pour le frontal. La vue sert principalement de cache et si nécessaire, crée un modèle intermédiaire afin de réaliser un caching suppémentaire. On a, je dirais, deux architectures 2 tiers.
L'application doit tourner sur une unique machine avec des specs bien déterminées : je ne saurais dire aujourd'hui si avec un serveur d'application EJB on pourrait passer.
2- Le langage pour faire les queries n'est ni OQL, ni SQL. Avez-vous déjà
constaté de graves lacunes? Peut-on aujourd'hui faire ce que nous avons
réussi à faire avec SQL?
- Pas d'equivalents de SELECT (oblige de faire plusieurs allers-retours
vers la DB, pas possible de recuperer des objets partiellement)
- Pas de curseurs scrollables
- Pas d'outer joins
- Pas d'API precise pour le cache
- Pas de cache incremental de relation ou batch
- Pas de verrouillage optimiste
C'est encore pire que ce que je pensais... Le fait de faire plusieurs allers-retours me refroidit déjà.
Si tu as fait une croix sur EJB (ce qui est une erreur si tu n'as jamais
experimente avec CMP 2.0, a mon avis), je recommande Hibernate plutot que
JDO.
Aujourd'hui on cherche un système pour remplacer notre mapping O/R. Je ne pense pas que les CMP 2.0 sont adaptés. J'ai testé à tire perso JBoss et JOnAS.
Ca marche bien, mais en charge? (ne me parlez pas de Weblogic, ca passera pas : question économique insoluble).
--
Cédric
