RE : JDO : suite...

[Eric Samson]

Title: Message

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

______________________

Eric Samson, LIBeLIS

Enterprise Information Access

www.libelis.com

-----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 :

1. 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.

2. 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. 

3. 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.

4. 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