Ce qui
ressort de tout cela � mes yeux, mais je n'oserais en aucune mani�re avoir la
pretention de donner une opinion g�n�rale :
- EJB (entity local + CMP2.0/CMR) et JDO s'affrontent sur le terrain du mapping objet relationnel ;
- Les EJB entity laissent un go�t amers pour ceux qui ont v�cus le d�but des EJB : difficult� � suivre les relations, co�t des appels avec RMI qui tuaient les performances, caching ...
- Ni EJB, ni JDO ne donnent les politiques de caches que ces serveurs d'objets s'engagent � respecter : cela revient donc � se placer sous la coupe d'un vendeur/implantation donn�.
- Ni EJB, ni JDO ne r�pondent correctement � la notion de query. A la rigueur, les EJB sont mieux plac�s puisqu'on peut pr�d�finir des requ�tes SQL dans les descripteurs : au moins on sait ce qu'on fait car une bonne requ�te SQL bien d�finie est toujours la meilleure amie des performances. J'ai test� JBoss sur ce point, et franchement cela me convient.
- Les transactions de JDO ont-elles la m�me s�mantique que ces des EJB?
Finallement, de quoi a-t-on besoin
:
- De pouvoir remonter des graphes d'objets "intelligemment". Parce que sinon, autant remonter un paquet d'objets s�rialis� dans un SGBD. JDO, EJB Entity?
- De suivre des relations qui ne sont pas forc�ment calqu�e sur la jointure de 2 tables.
- De pouvoir r�utiliser sans trop de peur un sch�ma relationnel d�j� existant : JDO ne r�pond pas � cela dans la spec que j'ai vu, et les EJB sont un peu simplistes (cf point pr�c�dent)
- De d�finir le "business logic" dans des unit�s autonomes et ind�pendantes. EJB Session stateless (� la rigueur stateful pour des transactions plus longues) r�pond � cette probl�matique.
-----Original Message-----
From: Eric Samson [mailto:[EMAIL PROTECTED]
Sent: vendredi 21 mars 2003 16:28
To: [EMAIL PROTECTED]
Subject: RE : JDO : suite...les affirmations sur les allers-retours et chargements partiels d'objets dans JDO sont totalement fantaisistes.C'est facile � v�rifier, il ne faut pas rester sur cette impression.Effectivement, la mont�e en charge et la libert� de choix d'infra-structure de d�ploiement sont 2 questions importantes.Cordialement-----Message d'origine-----
De : Olivier Richaud [mailto:[EMAIL PROTECTED]
Envoy� : vendredi 21 mars 2003 11:33
� : [EMAIL PROTECTED]
Objet : RE: JDO : suite...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 :
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
