Discussion :

[mickael.guilbert]

Bonjour,

Quand je mets à jour une donnée dans ma BDD via Toad + commit, je ne la retrouve pas dans mon application.

Cette info concerne un nouvel element qui devrait apparaitre dans une liste oneToMany en mode lazy.

A contient une liste de 3 B en lazy, apres la mise à jour via toad, en relançant le A.getBListe() je devrais avoir 4 B dans la liste. Mais j'en ai toujours que 3 .

j'aimerais bien trouver une soluce avant de passer à L'EJB-QL
Merci

[mickael.guilbert]

j'ai tenté le :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
A.getListB().size();
monRetour = A.getListB();

Le :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

.size()

semblait une bonne piste

[mickael.guilbert]

Précision :
Aprés 30 à 60 min, je peux enfin récuperer les bonnes infos.

Y a t il une option, un parametre ?

Env : Glassfish sun app server / EJB3 / JPA / TOPLINK / ORACLE

[mickael.guilbert]

Désolé, voici le vrai probleme :

Quand je mets à jour la bdd via une autre application, la couche de persistence ne prends en compte cette modification qu'aprés un long délais.

Connaissez vous un paramétre ou une option à ajouter(modifier) pour ne pas avoir de délais ?

Le probléme ne concerne pas les LAZY car quand je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
private EntityManager em;
HotelsSystem hotelSystem = em.find(HotelsSystem.class,hotelReference.getCode());

Et que j'ais modifié l'enregistrement de hotelSystem via Toad + commit, je ne retrouve pas l'info dans mon application.

[JeitEmgie]

Bonjour,

Quand je mets à jour une donnée dans ma BDD via Toad + commit, je ne la retrouve pas dans mon application.

Cette info concerne un nouvel element qui devrait apparaitre dans une liste oneToMany en mode lazy.

A contient une liste de 3 B en lazy, apres la mise à jour via toad, en relançant le A.getBListe() je devrais avoir 4 B dans la liste. Mais j'en ai toujours que 3 .

j'aimerais bien trouver une soluce avant de passer à L'EJB-QL
Merci

c'est un problème de cache, étant donné que vous modifiez la DB en dehors de la webapp, celle-ci n'a aucun autre moyen de constater une modification de la liste @OneToMany qu'en détectant une modification du "owner" de cette relation…

si vous avez un champ @Version dans ce dernier vous devriez le mettre à jour lorsque vous modifiez la liste @OneToMany dans Toad.

Peut-être aussi qu'en ajoutant un champ @Formula("( SELECT COUNT(*) FROM ONETOMANY_RELATED r WHERE r.ref_owner = id )") qui donc compte le nombre d'éléments de la relation @OneToMany et en y accédant en début du parcours de la liste, vous pourriez provoquer un rafraîchissement de la cache…


Aussi TopLink a la possibilité de spécifier
hints={@QueryHint(name="toplink.refresh", value="true")}
dans les @NamedQuery

Et reste encore la possibilité de provoquer un evict() à la demande d'un "owner" déterminé dans votre webapp…

[mickael.guilbert]

c'est un problème de cache, étant donné que vous modifiez la DB en dehors de la webapp, celle-ci n'a aucun autre moyen de constater une modification de la liste @OneToMany qu'en détectant une modification du "owner" de cette relation…

Sans parler de oneToMany (1 obj = une table), peut on etre sur que si je modifi un record, le find me ramenera bien les bonnes valeurs ?

Aussi TopLink a la possibilité de spécifier
hints={@QueryHint(name="toplink.refresh", value="true")}
dans les @NamedQuery
…

--> c'est parfait

[mickael.guilbert]

Sans parler de oneToMany (1 obj = une table), peut on etre sur que si je modifi un record, le find me ramenera bien les bonnes valeurs ?

Je viens de faire le test, ca ne marche pas

je fais un find sur un "utilisateur" & affiche son nom
Je vais dans la base et change son nom
Je refais un find sur cet "utilisateur" & son nom n'a pas changé.

PS : le 2 find sont dans 2 transactions differentes

[JeitEmgie]

Je viens de faire le test, ca ne marche pas

je fais un find sur un "utilisateur" & affiche son nom
Je vais dans la base et change son nom
Je refais un find sur cet "utilisateur" & son nom n'a pas changé.

PS : le 2 find sont dans 2 transactions differentes

1.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
em.refresh(user);

2.
en dehors des @NamedQuery :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
em.createQuery("…").setHint("toplink.refresh", "true")

3.
aussi possible :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
em.createQuery("…").setHint("toplink.pessimistic-lock", "Lock")

[mickael.guilbert]

Pour toutes les recherches qui nécessitent une requete EJB-QL et dont les infos dans la base sont suceptibles de changer , j'ai fais le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
@NamedQuery(name = "Hotels.findAllBetween2Date", 
                query = "SELECT h from Hotels h WHERE h.hdi=:hotelId AND ...",
                hints={@QueryHint(name="toplink.refresh", value="true")})

et ça fonctionne tres bien (merci)

Sinon pour les chargements depuis un "find" sur certains objets je serais obligé de faire un "refresh" juste apres ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
em.find(userKiPeutEtreModifiéParAppliExterne)
em.refresh(userKiPeutEtreModifiéParAppliExterne)

[JeitEmgie]

Pour toutes les recherches qui nécessitent une requete EJB-QL et dont les infos dans la base sont suceptibles de changer , j'ai fais le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
@NamedQuery(name = "Hotels.findAllBetween2Date", 
                query = "SELECT h from Hotels h WHERE h.hdi=:hotelId AND ...",
                hints={@QueryHint(name="toplink.refresh", value="true")})

et ça fonctionne tres bien (merci)

Sinon pour les chargements depuis un "find" sur certains objets je serais obligé de faire un "refresh" juste apres ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
em.find(userKiPeutEtreModifiéParAppliExterne)
em.refresh(userKiPeutEtreModifiéParAppliExterne)

sauf que le refresh prend comme paramètre l'entity pas sa PK…

[mickael.guilbert]

oui bien sur, c'etait pour aller vite.

Je trouve ca dommage que la couche de persitance ne soit pas capable de détecter (via des process) les changements des données. Surtout que le pool de connexion est paramétré au niveau du serveur d'appli.

Ce mécanisme ne s'integre pas bien dans un si tres hétérogène (la plus part des pme)

[JeitEmgie]

oui bien sur, c'etait pour aller vite.

Je trouve ca dommage que la couche de persitance ne soit pas capable de détecter (via des process) les chgt des données. Surtout que le pool de connexion est paramétré au niveau du serveur d'appli.

Ce mécanisme ne s'integre pas bien dans un si tres hétérogéne (la + part des pme)

si vous avez un champ annoté @Version, par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
	@Version
	@Column(name="optlock")
	protected int versionNum ;

(optlock pour optimistic lock…) alors la couche de persistence sera capable de détecter que la version en cache n'est pas synchrone avec la version en DB…
si vos modifications hors application incrémentent ce champ…

[mickael.guilbert]

si vous avez un champ annoté @Version, par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
	@Version
	@Column(name="optlock")
	protected int versionNum ;

(optlock pour optimistic lock…) alors la couche de persistence sera capable de détecter que la version en cache n'est pas synchrone avec la version en DB…
si vos modifications hors application incrémentent ce champ…

Oui j'avais vu ce truc, mais cela implique de modifiier les appli externes (quand c'est possible) qui mettent à jour ces données.

Je vais attendre un peu avant de taguer ce post en résolu, pour voir si un truc miracle n'est pas encore possible.
Merci beaucoup pour ton aide.

[mickael.guilbert]

Et en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
toplink.cache.type.<ENTITY>
= NONE

mon entity ne devrait pas etre en cache ?
Comment peut on vérifier cela ?

[JeitEmgie]

Et en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
toplink.cache.type.<ENTITY>
= NONE

mon entity ne devrait pas etre en cache ?
Comment peut on vérifier cela ?

attention : quand on utilise cela il faut aussi que toutes les entités qui sont reliées à <ENTITY> par des @oneToMany et @ManyToMany soient aussi avec la même politique de cache…

donc par cascading, vous voyez très vite que dans la plupart des applications cela revient à tirer "sur le fil de la pelotte"… et perdre tout le bénéfice d'une cache …

cache.type = NONE est uniquement utile pour des ENTITY "feuilles" dans l'arbre des relations entre entités ou pour des ENTITY totalement indépendantes du reste (un log par exemple…)