JAVA , Base de données Appli Web

JCR

25/09/2003 à 21:44

Je me demande si il ne serait pas plus judicieux de faire une requete dans
la BDD à chaque login pour chaque utilisateur dés que c'est nécessaire.
(dans ce cas la BDD sera beaucoup plus souvent solicité). Qu'elle est
d'après vous le mieux ? Qu'est ce qui est fait en général pour les
problémes

de ce type ?
A première vue, c'est un peu bizarre de mettre tous les uti en mémoire.

C'est quoi la couche de persistance utilisée ? JDBC "direct", hibernate,
toplink, jdo ?
Si c'est le premier, bon... pourquoi pas.
Si c'est l'une des autres, alors c'est certainement une mauvaise solution
car ces trois solutions gèrent des caches qui rendent inutile de monter les
tables en mémoire.
Ensuite s'il n'y a que quelques dizaines d'uti dans la table... et bien ça
ne doit pas utiliser tant de mémoire que ça. Limiter les A/R appli<->Bdd
c'est pas mal.

Etant donné que je dois apporter beaucoup de modifications, je me demande
si

je ne devrais pas repenser toute l'appli sous la forme J2EE, EJB... Enfin
je

n'ai pas encore assez de recul pour connaitre l'avantage de ceci par
rapport

à un simple (servlet + JSP) mais ca me permetrait de me familiariser avec
J2EE. Comment déterminer quel technologie employer ?
Ré-écrire l'appli en passant d'une architecture servlets+composants à une

architecture ejb c'est loin d'être anodin, c'est se lancer dans une
ré-écriture complète de l'appli. Si t'as le budget pour...
Mais il ne faut pas faire de l'ejb à tout prix. On peut faire des applis
sérieuses et robustes en respectant un développpement en couches
indépendantes et en utilisant un outil de mapping performant tel que
hibernate.
Par développement en couches j'entends : respecter MVC avec par exemple
struts + une partie modèle "propre".

(PS: au passage, les servlets font parties de J2EE donc dire quelquechose du
style "passer des servlets à j2ee" n'a pas de sens)

JC

jeje900ss

25/09/2003 à 23:27

Salut,

A première vue, c'est un peu bizarre de mettre tous les uti en mémoire.
C'est quoi la couche de persistance utilisée ? JDBC "direct", hibernate,
toplink, jdo ?

C'est du JDBC "direct"

Si c'est le premier, bon... pourquoi pas.
Si c'est l'une des autres, alors c'est certainement une mauvaise solution
car ces trois solutions gèrent des caches qui rendent inutile de monter
les

tables en mémoire.

Ah ca c'est interessant, je vais me documenter la dessus.

Ensuite s'il n'y a que quelques dizaines d'uti dans la table... et bien ça
ne doit pas utiliser tant de mémoire que ça. Limiter les A/R appli<->Bdd
c'est pas mal.

Oui t'as raison, je penses et j'espere que à terme il y aura beaucoup
beaucoup d'utilisateurs...

Ré-écrire l'appli en passant d'une architecture servlets+composants à une
architecture ejb c'est loin d'être anodin, c'est se lancer dans une
ré-écriture complète de l'appli.

Oui surtout que je n'ai qu'une connaissance théorique (trés peu de pratique)
sur EJB donc encore plus long ;-)

Mais il ne faut pas faire de l'ejb à tout prix. On peut faire des applis
sérieuses et robustes en respectant un développpement en couches
indépendantes et en utilisant un outil de mapping performant tel que
hibernate.

J'ai pas suffisament de recul pour comprendre vraiment les avantages et
bénéfices de "l'ejb". Enfin je vais essayer de peser quand meme le pour et
le contre spécifiquement pour mon appli.

Par développement en couches j'entends : respecter MVC avec par exemple
struts + une partie modèle "propre".

ok

Merci pour toutes ces précisions. :-)

Jérôme

Arnaud Roger

26/09/2003 à 10:11

Si c'est le premier, bon... pourquoi pas.
Si c'est l'une des autres, alors c'est certainement une mauvaise
solution

car ces trois solutions gèrent des caches qui rendent inutile de monter
les

tables en mémoire.

Ah ca c'est interessant, je vais me documenter la dessus.
hibernate utilise JCS pour gere le cache, si jamais le passage en tout

hibernate peut etre couteux il peut etre interessant d'utiliser JCS
directement (dans le projet turbine sur java.apache.orgr) avec un wrapper
des DAO qui delegue a l'implementation sans cache si l'objet ne se trouve
pas dans jcs par exemple

Arnaud R.

seb

16/10/2003 à 14:13

Bonjour à tous! :)

Bon, je profite de ce sujet pour 'rebondir' et l'étendre un peu! ;)

Je sors d'une appli qui présente exactement le même concept: un objet
'fournisseur' charge tous les utilisateurs (objet 'Employee', 700
employés environ) existants à l'init et je passe par lui pour récup érer
la liste. Je dispose donc d'une collection d'utilisateur stocké dans un
objet BasicCollection, ce dernier possédant des méthodes utiles (tris ,
entre autre, pour renvoyer des sous ensemble des utilisateurs, etc).
Dans le cadre de mon application, ce choix me semble judicieux: en
effet, il s'agit d'un intranet qui propose de nombreuses fonctions
d'affichages de fiches utilisateurs, de tris par site de travail,
trombinoscope etc etc... bref, beaucoup de tris et de manipulation sur
ces objets "Employee".

Le nouveau DI, en découvrant ce qui a été fait sur l'appli tombe de s
nues "quoi, vous charger tous les utilisateurs en mémoire? Mais non fau t
pas faire ca il faut faire des requête à la base, tu surcharge ta
mémoire pour rien!"

Faire des requêtes à chaque fois que quelqu'un clique sur une page
'trier par...' me semble complètement débile ... alors que l'aspect
chargement de la collection (syncronisation maison avec la base, au
passage) me semble une solution certe plus couteuse en mémoire mais
beaucoup plus élégante!
Surtout que au niveau chargement en mémoire de collections d'objet, il
n'y a guêre que la collection d'employés qui pèse...

Alors, qu'en pensez vous? Quelle limite devrait t'on fixer a votre avis
à une telle opération de chargement? (700 objets utilisateur me sembl e
peu... surtout avec 512 meg de ram et un bi-pro...)

Nicolas Delsaux

16/10/2003 à 15:00

Le 16.10 2003, seb s'est levé(e) et s'est dit "tiens, je
vais écrire aux mecs de fr.comp.lang.java"

Bonjour à tous! :)

Bon, je profite de ce sujet pour 'rebondir' et l'étendre un peu! ;)

Le nouveau DI, en découvrant ce qui a été fait sur l'appli tombe des
nues "quoi, vous charger tous les utilisateurs en mémoire? Mais non faut
pas faire ca il faut faire des requête à la base, tu surcharge ta
mémoire pour rien!"

Alors, qu'en pensez vous? Quelle limite devrait t'on fixer a votre avis
à une telle opération de chargement? (700 objets utilisateur me semble
peu... surtout avec 512 meg de ram et un bi-pro...)

La question n'est pas bonne. Evidement, dans la mesure où tes accès SGBD

sont beaucoup plus longs que l'accès à ta collection Java, ta méthode
"semble" plus avantageuse, dans la mesure où le code Java tourne beaucoup
plus vite. Cependant, tu rencontreras tôt ou tard un problème de taille de
cette collection dû à deux problèmes :
- augmentation du nombre d'objets
- augmentation du nombre de champs dans ces objets
Pour éviter ça, plusieurs solutions s'offrent à toi :
- ne gérer que les attributs utilisés dans tes tris, et ne charger
complètement que les employés dont tu affiche la fiche
- utiliser une weakhashmap, ou tout autre collection permettant d'oublier
peu à peu des données, ce qui évitera une surcharge du serveur.

Enfin, ça ça n'est que l'avis de quelqu'un qui n'a jamais touché aux EJBs.
peut-être y a-t-il là une solution plus élégante, dont Jérôme pourra te
parler.

--
Nicolas Delsaux
"Dans l'espace, personne ne vous entend crier"
Alien, le 8ème passager

seb

17/10/2003 à 08:48

Bonjour,

alors:

plus vite. Cependant, tu rencontreras tôt ou tard un problème de ta ille de
cette collection dû à deux problèmes :
- augmentation du nombre d'objets
Oui, bien sûr! Mais dans mon cas, le nombre d'employé ne doublera pas ,

compte tenu de la politique de la société. Je ne dépasserais donc
probablement pas la taille de 1000 employés au pire. Ca me semble donc
encore raisonnable! :) (et puis ce ne sont pas de gros objets...)

- augmentation du nombre de champs dans ces objets
Hum... Peu probable... un appli bien concue à mon avis ne va pas voir l e

nombre de champs doubler du jour au lendemain.

Pour éviter ça, plusieurs solutions s'offrent à toi :
- ne gérer que les attributs utilisés dans tes tris, et ne charger
complètement que les employés dont tu affiche la fiche
Tout a fait, c'est une possibilitée envisagée en effet pour

"eventuellement" décharger un peu tout ca.

- utiliser une weakhashmap, ou tout autre collection permettant d'oubl ier
peu à peu des données, ce qui évitera une surcharge du serveur.
Bon. Pourrais tu développer un peu car je ne connais malheureusement pa s

les weakhashmap... :(

Enfin, ça ça n'est que l'avis de quelqu'un qui n'a jamais touché aux EJBs.
peut-être y a-t-il là une solution plus élégante, dont Jérô me pourra te
parler.
Je n'aime pas trop les ejbs... trop usine à gaz!!

Bon, en tous cas merci pour ton avis! :)

Ceci dit, même en prenant en compte tous ces aspects, cela ne justifie
quand meme toujours pas à mon humble avis une requete envoyée au serv eur
a chaque affichage d'une vue du site par un utilisateur... ou est le M
de MVC dans un tel cas? Non, extraire à la demande des objets
'temporaires' juste pour un affichage ponctuel me semble lourdingue:
accès base, parsing du resultset, blabla... plus autant de requêtes à
écrire que de cas de tris, de recherche, etc... on se croirait à fair e
du php... :p

Nicolas Delsaux

17/10/2003 à 12:09

Le 17.10 2003, seb s'est levé(e) et s'est dit "tiens, je
vais écrire aux mecs de fr.comp.lang.java"

Bonjour,

Oui, bien sûr! Mais dans mon cas, le nombre d'employé ne doublera pas,
compte tenu de la politique de la société. Je ne dépasserais donc
probablement pas la taille de 1000 employés au pire. Ca me semble donc
encore raisonnable! :) (et puis ce ne sont pas de gros objets...)

Tout dépend de la machine sur laquelle tourne l'appli, en fait.

Hum... Peu probable... un appli bien concue à mon avis ne va pas voir
le nombre de champs doubler du jour au lendemain.

Même sns doubler, l'ajout d'un ou deux champs pourrait augmenter la
taille de tes objets, non ?

Tout a fait, c'est une possibilitée envisagée en effet pour
"eventuellement" décharger un peu tout ca.

Je te la déconseille toutefois, car elle induit la mise en place de
mécanismes de vérifications de validité de tes objets, assez lourds à
coder (typiquement, plaquer des if(toto!=null) partout).

Bon. Pourrais tu développer un peu car je ne connais malheureusement
pas les weakhashmap... :(

Eh, eh ! C'est une collection du package java.util implémentant

l'interface Map. Son principal secret est de fournir des clés
n'interdisant pas le déréférencement. Ce qui fait qu'un objet de cette
table peut être garbage collecté. Ca diminue l'empreinte mémoire, mais en
contrepartie ton objet est perdu. L'avantage dans ton cas, c'est que tes
objets peuvent être recréés à partir de la base. En fait, ça revient
simplement à dispsoer d'un cache de données indépendant de ta base.

Ceci dit, même en prenant en compte tous ces aspects, cela ne justifie
quand meme toujours pas à mon humble avis une requete envoyée au
serveur a chaque affichage d'une vue du site par un utilisateur...

Bien sûr que non ! L'objectif est de décorréler au maximum l'accès au
SGBD et les accès du client.

Je te conseille quand même de jeter un coup d'oeil à des outils de
mapping O/R, comme OJB et autres, qui devraient te permettre de conserver
des objets Java correspondant au contenu de ta base, sans avoir à te
faire de souci sur les accès à celle-ci. Enfin, je crois.

--
Nicolas Delsaux
PM > L'un prône la franchouillardise grasse, et l'autre le plaisir
PM > sensuel par la décharge d'armes lourdes, donc un américanisme gras
in fras, Taxi vs Terminator

Le 17.10 2003, seb <omera@free.fr> s'est levé(e) et s'est dit "tiens, je
vais écrire aux mecs de fr.comp.lang.java"

Bonjour,

Oui, bien sûr! Mais dans mon cas, le nombre d'employé ne doublera pas,
compte tenu de la politique de la société. Je ne dépasserais donc
probablement pas la taille de 1000 employés au pire. Ca me semble donc
encore raisonnable! :) (et puis ce ne sont pas de gros objets...)

Tout dépend de la machine sur laquelle tourne l'appli, en fait.

Hum... Peu probable... un appli bien concue à mon avis ne va pas voir
le nombre de champs doubler du jour au lendemain.

Même sns doubler, l'ajout d'un ou deux champs pourrait augmenter la
taille de tes objets, non ?

Tout a fait, c'est une possibilitée envisagée en effet pour
"eventuellement" décharger un peu tout ca.

Je te la déconseille toutefois, car elle induit la mise en place de
mécanismes de vérifications de validité de tes objets, assez lourds à
coder (typiquement, plaquer des if(toto!=null) partout).

Bon. Pourrais tu développer un peu car je ne connais malheureusement
pas les weakhashmap... :(

Eh, eh ! C'est une collection du package java.util implémentant

l'interface Map. Son principal secret est de fournir des clés
n'interdisant pas le déréférencement. Ce qui fait qu'un objet de cette
table peut être garbage collecté. Ca diminue l'empreinte mémoire, mais en
contrepartie ton objet est perdu. L'avantage dans ton cas, c'est que tes
objets peuvent être recréés à partir de la base. En fait, ça revient
simplement à dispsoer d'un cache de données indépendant de ta base.

Ceci dit, même en prenant en compte tous ces aspects, cela ne justifie
quand meme toujours pas à mon humble avis une requete envoyée au
serveur a chaque affichage d'une vue du site par un utilisateur...

Bien sûr que non ! L'objectif est de décorréler au maximum l'accès au
SGBD et les accès du client.

Je te conseille quand même de jeter un coup d'oeil à des outils de
mapping O/R, comme OJB et autres, qui devraient te permettre de conserver
des objets Java correspondant au contenu de ta base, sans avoir à te
faire de souci sur les accès à celle-ci. Enfin, je crois.

--
Nicolas Delsaux
PM > L'un prône la franchouillardise grasse, et l'autre le plaisir
PM > sensuel par la décharge d'armes lourdes, donc un américanisme gras
in fras, Taxi vs Terminator

Vous avez filtré cet utilisateur ! Consultez son message

Le 17.10 2003, seb s'est levé(e) et s'est dit "tiens, je
vais écrire aux mecs de fr.comp.lang.java"

Bonjour,

Oui, bien sûr! Mais dans mon cas, le nombre d'employé ne doublera pas,
compte tenu de la politique de la société. Je ne dépasserais donc
probablement pas la taille de 1000 employés au pire. Ca me semble donc
encore raisonnable! :) (et puis ce ne sont pas de gros objets...)

Tout dépend de la machine sur laquelle tourne l'appli, en fait.

Hum... Peu probable... un appli bien concue à mon avis ne va pas voir
le nombre de champs doubler du jour au lendemain.

Même sns doubler, l'ajout d'un ou deux champs pourrait augmenter la
taille de tes objets, non ?

Tout a fait, c'est une possibilitée envisagée en effet pour
"eventuellement" décharger un peu tout ca.

Je te la déconseille toutefois, car elle induit la mise en place de
mécanismes de vérifications de validité de tes objets, assez lourds à
coder (typiquement, plaquer des if(toto!=null) partout).

Bon. Pourrais tu développer un peu car je ne connais malheureusement
pas les weakhashmap... :(

Eh, eh ! C'est une collection du package java.util implémentant

l'interface Map. Son principal secret est de fournir des clés
n'interdisant pas le déréférencement. Ce qui fait qu'un objet de cette
table peut être garbage collecté. Ca diminue l'empreinte mémoire, mais en
contrepartie ton objet est perdu. L'avantage dans ton cas, c'est que tes
objets peuvent être recréés à partir de la base. En fait, ça revient
simplement à dispsoer d'un cache de données indépendant de ta base.

Ceci dit, même en prenant en compte tous ces aspects, cela ne justifie
quand meme toujours pas à mon humble avis une requete envoyée au
serveur a chaque affichage d'une vue du site par un utilisateur...

Bien sûr que non ! L'objectif est de décorréler au maximum l'accès au
SGBD et les accès du client.

Je te conseille quand même de jeter un coup d'oeil à des outils de
mapping O/R, comme OJB et autres, qui devraient te permettre de conserver
des objets Java correspondant au contenu de ta base, sans avoir à te
faire de souci sur les accès à celle-ci. Enfin, je crois.

--
Nicolas Delsaux
PM > L'un prône la franchouillardise grasse, et l'autre le plaisir
PM > sensuel par la décharge d'armes lourdes, donc un américanisme gras
in fras, Taxi vs Terminator

seb

17/10/2003 à 14:17

Re, ;)

Hum... Peu probable... un appli bien concue à mon avis ne va pas voir
le nombre de champs doubler du jour au lendemain.
Même sns doubler, l'ajout d'un ou deux champs pourrait augmenter la

taille de tes objets, non ?
C'est vrai... c'est un argument a peser.

Tout a fait, c'est une possibilitée envisagée en effet pour
"eventuellement" décharger un peu tout ca.
Je te la déconseille toutefois, car elle induit la mise en place de

mécanismes de vérifications de validité de tes objets, assez lour ds à
coder (typiquement, plaquer des if(toto!=null) partout).
tout a fait!

Ou alors faire un mécanisme interne? Utilisation du design pattern Prox y
ou approchant? Bref... :)

Eh, eh ! C'est une collection du package java.util implémentant
l'interface Map. Son principal secret est de fournir des clés
n'interdisant pas le déréférencement. Ce qui fait qu'un objet de cette
table peut être garbage collecté. Ca diminue l'empreinte mémoire, mais en
contrepartie ton objet est perdu. L'avantage dans ton cas, c'est que te s
objets peuvent être recréés à partir de la base. En fait, ça revient
simplement à dispsoer d'un cache de données indépendant de ta bas e.
Ca a l'air tres bien tout ca, mais comment peut on compter sur une

collection qui se vide 'toute seule' (si j'ai ien compris?) Si ej
cherche un objet qui a été 'garbage collecté" et que ca me renvoit
null,commetn savoir si l'objet n'existe plus(donc a rerécupérer) ou n 'a
jamais existé?

Bien sûr que non ! L'objectif est de décorréler au maximum l'accè s au
SGBD et les accès du client.
Ca me fait plaisir de te l'entendre dire! :)

En entendant certain "haut placés" hiérarchiquement proférer de tel s
trucs, je doute parfois des mes compétences (suis je débile, ai je lo upé
le coche???) ou de ma santé mentale.. ;)

Je te conseille quand même de jeter un coup d'oeil à des outils de
mapping O/R, comme OJB et autres, qui devraient te permettre de conserv er
des objets Java correspondant au contenu de ta base, sans avoir à te
faire de souci sur les accès à celle-ci. Enfin, je crois.
Et bien ma fois j'ai commencé à regarder! :)

Mon souci : quelle solution choisir? Rien que JDO, il en existe
plusieurs implémentations par un tas de société différentes... et puis
il y a des trucs comme hibernate... bref! Beaucoup de choix, peu de
conseils pour orienter vers une solution pérenne à long terme.. bref
encore un peu flou! :)

Re, ;)

Hum... Peu probable... un appli bien concue à mon avis ne va pas voir
le nombre de champs doubler du jour au lendemain.
Même sns doubler, l'ajout d'un ou deux champs pourrait augmenter la

taille de tes objets, non ?
C'est vrai... c'est un argument a peser.

Tout a fait, c'est une possibilitée envisagée en effet pour
"eventuellement" décharger un peu tout ca.
Je te la déconseille toutefois, car elle induit la mise en place de

mécanismes de vérifications de validité de tes objets, assez lour ds à
coder (typiquement, plaquer des if(toto!=null) partout).
tout a fait!

Ou alors faire un mécanisme interne? Utilisation du design pattern Prox y
ou approchant? Bref... :)

Eh, eh ! C'est une collection du package java.util implémentant
l'interface Map. Son principal secret est de fournir des clés
n'interdisant pas le déréférencement. Ce qui fait qu'un objet de cette
table peut être garbage collecté. Ca diminue l'empreinte mémoire, mais en
contrepartie ton objet est perdu. L'avantage dans ton cas, c'est que te s
objets peuvent être recréés à partir de la base. En fait, ça revient
simplement à dispsoer d'un cache de données indépendant de ta bas e.
Ca a l'air tres bien tout ca, mais comment peut on compter sur une

collection qui se vide 'toute seule' (si j'ai ien compris?) Si ej
cherche un objet qui a été 'garbage collecté" et que ca me renvoit
null,commetn savoir si l'objet n'existe plus(donc a rerécupérer) ou n 'a
jamais existé?

Bien sûr que non ! L'objectif est de décorréler au maximum l'accè s au
SGBD et les accès du client.
Ca me fait plaisir de te l'entendre dire! :)

En entendant certain "haut placés" hiérarchiquement proférer de tel s
trucs, je doute parfois des mes compétences (suis je débile, ai je lo upé
le coche???) ou de ma santé mentale.. ;)

Je te conseille quand même de jeter un coup d'oeil à des outils de
mapping O/R, comme OJB et autres, qui devraient te permettre de conserv er
des objets Java correspondant au contenu de ta base, sans avoir à te
faire de souci sur les accès à celle-ci. Enfin, je crois.
Et bien ma fois j'ai commencé à regarder! :)

Mon souci : quelle solution choisir? Rien que JDO, il en existe
plusieurs implémentations par un tas de société différentes... et puis
il y a des trucs comme hibernate... bref! Beaucoup de choix, peu de
conseils pour orienter vers une solution pérenne à long terme.. bref
encore un peu flou! :)

Vous avez filtré cet utilisateur ! Consultez son message

Re, ;)

Hum... Peu probable... un appli bien concue à mon avis ne va pas voir
le nombre de champs doubler du jour au lendemain.
Même sns doubler, l'ajout d'un ou deux champs pourrait augmenter la

taille de tes objets, non ?
C'est vrai... c'est un argument a peser.

Tout a fait, c'est une possibilitée envisagée en effet pour
"eventuellement" décharger un peu tout ca.
Je te la déconseille toutefois, car elle induit la mise en place de

mécanismes de vérifications de validité de tes objets, assez lour ds à
coder (typiquement, plaquer des if(toto!=null) partout).
tout a fait!

Ou alors faire un mécanisme interne? Utilisation du design pattern Prox y
ou approchant? Bref... :)

Eh, eh ! C'est une collection du package java.util implémentant
l'interface Map. Son principal secret est de fournir des clés
n'interdisant pas le déréférencement. Ce qui fait qu'un objet de cette
table peut être garbage collecté. Ca diminue l'empreinte mémoire, mais en
contrepartie ton objet est perdu. L'avantage dans ton cas, c'est que te s
objets peuvent être recréés à partir de la base. En fait, ça revient
simplement à dispsoer d'un cache de données indépendant de ta bas e.
Ca a l'air tres bien tout ca, mais comment peut on compter sur une

collection qui se vide 'toute seule' (si j'ai ien compris?) Si ej
cherche un objet qui a été 'garbage collecté" et que ca me renvoit
null,commetn savoir si l'objet n'existe plus(donc a rerécupérer) ou n 'a
jamais existé?

Bien sûr que non ! L'objectif est de décorréler au maximum l'accè s au
SGBD et les accès du client.
Ca me fait plaisir de te l'entendre dire! :)

En entendant certain "haut placés" hiérarchiquement proférer de tel s
trucs, je doute parfois des mes compétences (suis je débile, ai je lo upé
le coche???) ou de ma santé mentale.. ;)

Je te conseille quand même de jeter un coup d'oeil à des outils de
mapping O/R, comme OJB et autres, qui devraient te permettre de conserv er
des objets Java correspondant au contenu de ta base, sans avoir à te
faire de souci sur les accès à celle-ci. Enfin, je crois.
Et bien ma fois j'ai commencé à regarder! :)

Mon souci : quelle solution choisir? Rien que JDO, il en existe
plusieurs implémentations par un tas de société différentes... et puis
il y a des trucs comme hibernate... bref! Beaucoup de choix, peu de
conseils pour orienter vers une solution pérenne à long terme.. bref
encore un peu flou! :)

cilovie

17/10/2003 à 21:20

Et LDAP alors !!
Il me semble que pour des ensembles de type entreprise / employés c'est ce
qu'il y a de mieux.
De plus pour les accès en lecture c'est le plus performant.

"seb" a écrit dans le message de news:
3f8fdce5$0$2770$
Re, ;)

Hum... Peu probable... un appli bien concue à mon avis ne va pas voir
le nombre de champs doubler du jour au lendemain.
Même sns doubler, l'ajout d'un ou deux champs pourrait augmenter la

taille de tes objets, non ?
C'est vrai... c'est un argument a peser.

Tout a fait, c'est une possibilitée envisagée en effet pour
"eventuellement" décharger un peu tout ca.
Je te la déconseille toutefois, car elle induit la mise en place de

mécanismes de vérifications de validité de tes objets, assez lourds à
coder (typiquement, plaquer des if(toto!=null) partout).
tout a fait!

Ou alors faire un mécanisme interne? Utilisation du design pattern Proxy
ou approchant? Bref... :)

Eh, eh ! C'est une collection du package java.util implémentant
l'interface Map. Son principal secret est de fournir des clés
n'interdisant pas le déréférencement. Ce qui fait qu'un objet de cette
table peut être garbage collecté. Ca diminue l'empreinte mémoire, mais en
contrepartie ton objet est perdu. L'avantage dans ton cas, c'est que tes
objets peuvent être recréés à partir de la base. En fait, ça revient
simplement à dispsoer d'un cache de données indépendant de ta base.
Ca a l'air tres bien tout ca, mais comment peut on compter sur une

collection qui se vide 'toute seule' (si j'ai ien compris?) Si ej
cherche un objet qui a été 'garbage collecté" et que ca me renvoit
null,commetn savoir si l'objet n'existe plus(donc a rerécupérer) ou n'a
jamais existé?

Bien sûr que non ! L'objectif est de décorréler au maximum l'accès au
SGBD et les accès du client.
Ca me fait plaisir de te l'entendre dire! :)

En entendant certain "haut placés" hiérarchiquement proférer de tels
trucs, je doute parfois des mes compétences (suis je débile, ai je loupé
le coche???) ou de ma santé mentale.. ;)

Je te conseille quand même de jeter un coup d'oeil à des outils de
mapping O/R, comme OJB et autres, qui devraient te permettre de conserver
des objets Java correspondant au contenu de ta base, sans avoir à te
faire de souci sur les accès à celle-ci. Enfin, je crois.
Et bien ma fois j'ai commencé à regarder! :)

Mon souci : quelle solution choisir? Rien que JDO, il en existe
plusieurs implémentations par un tas de société différentes... et puis
il y a des trucs comme hibernate... bref! Beaucoup de choix, peu de
conseils pour orienter vers une solution pérenne à long terme.. bref
encore un peu flou! :)

Et LDAP alors !!
Il me semble que pour des ensembles de type entreprise / employés c'est ce
qu'il y a de mieux.
De plus pour les accès en lecture c'est le plus performant.

"seb" <omera@free.fr> a écrit dans le message de news:
3f8fdce5$0$2770$626a54ce@news.free.fr...
Re, ;)

Hum... Peu probable... un appli bien concue à mon avis ne va pas voir
le nombre de champs doubler du jour au lendemain.
Même sns doubler, l'ajout d'un ou deux champs pourrait augmenter la

taille de tes objets, non ?
C'est vrai... c'est un argument a peser.

Tout a fait, c'est une possibilitée envisagée en effet pour
"eventuellement" décharger un peu tout ca.
Je te la déconseille toutefois, car elle induit la mise en place de

mécanismes de vérifications de validité de tes objets, assez lourds à
coder (typiquement, plaquer des if(toto!=null) partout).
tout a fait!

Ou alors faire un mécanisme interne? Utilisation du design pattern Proxy
ou approchant? Bref... :)

Eh, eh ! C'est une collection du package java.util implémentant
l'interface Map. Son principal secret est de fournir des clés
n'interdisant pas le déréférencement. Ce qui fait qu'un objet de cette
table peut être garbage collecté. Ca diminue l'empreinte mémoire, mais en
contrepartie ton objet est perdu. L'avantage dans ton cas, c'est que tes
objets peuvent être recréés à partir de la base. En fait, ça revient
simplement à dispsoer d'un cache de données indépendant de ta base.
Ca a l'air tres bien tout ca, mais comment peut on compter sur une

collection qui se vide 'toute seule' (si j'ai ien compris?) Si ej
cherche un objet qui a été 'garbage collecté" et que ca me renvoit
null,commetn savoir si l'objet n'existe plus(donc a rerécupérer) ou n'a
jamais existé?

Bien sûr que non ! L'objectif est de décorréler au maximum l'accès au
SGBD et les accès du client.
Ca me fait plaisir de te l'entendre dire! :)

En entendant certain "haut placés" hiérarchiquement proférer de tels
trucs, je doute parfois des mes compétences (suis je débile, ai je loupé
le coche???) ou de ma santé mentale.. ;)

Je te conseille quand même de jeter un coup d'oeil à des outils de
mapping O/R, comme OJB et autres, qui devraient te permettre de conserver
des objets Java correspondant au contenu de ta base, sans avoir à te
faire de souci sur les accès à celle-ci. Enfin, je crois.
Et bien ma fois j'ai commencé à regarder! :)

Mon souci : quelle solution choisir? Rien que JDO, il en existe
plusieurs implémentations par un tas de société différentes... et puis
il y a des trucs comme hibernate... bref! Beaucoup de choix, peu de
conseils pour orienter vers une solution pérenne à long terme.. bref
encore un peu flou! :)

Vous avez filtré cet utilisateur ! Consultez son message

Et LDAP alors !!
Il me semble que pour des ensembles de type entreprise / employés c'est ce
qu'il y a de mieux.
De plus pour les accès en lecture c'est le plus performant.

"seb" a écrit dans le message de news:
3f8fdce5$0$2770$
Re, ;)

Hum... Peu probable... un appli bien concue à mon avis ne va pas voir
le nombre de champs doubler du jour au lendemain.
Même sns doubler, l'ajout d'un ou deux champs pourrait augmenter la

taille de tes objets, non ?
C'est vrai... c'est un argument a peser.

Tout a fait, c'est une possibilitée envisagée en effet pour
"eventuellement" décharger un peu tout ca.
Je te la déconseille toutefois, car elle induit la mise en place de

mécanismes de vérifications de validité de tes objets, assez lourds à
coder (typiquement, plaquer des if(toto!=null) partout).
tout a fait!

Ou alors faire un mécanisme interne? Utilisation du design pattern Proxy
ou approchant? Bref... :)

Eh, eh ! C'est une collection du package java.util implémentant
l'interface Map. Son principal secret est de fournir des clés
n'interdisant pas le déréférencement. Ce qui fait qu'un objet de cette
table peut être garbage collecté. Ca diminue l'empreinte mémoire, mais en
contrepartie ton objet est perdu. L'avantage dans ton cas, c'est que tes
objets peuvent être recréés à partir de la base. En fait, ça revient
simplement à dispsoer d'un cache de données indépendant de ta base.
Ca a l'air tres bien tout ca, mais comment peut on compter sur une

collection qui se vide 'toute seule' (si j'ai ien compris?) Si ej
cherche un objet qui a été 'garbage collecté" et que ca me renvoit
null,commetn savoir si l'objet n'existe plus(donc a rerécupérer) ou n'a
jamais existé?

Bien sûr que non ! L'objectif est de décorréler au maximum l'accès au
SGBD et les accès du client.
Ca me fait plaisir de te l'entendre dire! :)

En entendant certain "haut placés" hiérarchiquement proférer de tels
trucs, je doute parfois des mes compétences (suis je débile, ai je loupé
le coche???) ou de ma santé mentale.. ;)

Je te conseille quand même de jeter un coup d'oeil à des outils de
mapping O/R, comme OJB et autres, qui devraient te permettre de conserver
des objets Java correspondant au contenu de ta base, sans avoir à te
faire de souci sur les accès à celle-ci. Enfin, je crois.
Et bien ma fois j'ai commencé à regarder! :)

Mon souci : quelle solution choisir? Rien que JDO, il en existe
plusieurs implémentations par un tas de société différentes... et puis
il y a des trucs comme hibernate... bref! Beaucoup de choix, peu de
conseils pour orienter vers une solution pérenne à long terme.. bref
encore un peu flou! :)

jerome moliere

18/10/2003 à 17:54

cilovie wrote:

Et LDAP alors !!
Il me semble que pour des ensembles de type entreprise / employés c'est ce
qu'il y a de mieux.
De plus pour les accès en lecture c'est le plus performant.

sacré farceur :)
on propage des légendes urbaines ?
troll trop gros pour passer ....

Jerome

JAVA , Base de données Appli Web

10 réponses

Veuillez sélectionner un problème