Re: [sdx-users] RE : Caching (était : Re: [sdx-users] pb avec la requete id)

[Pierrick Brihaye]

Re,

Martin Sévigny wrote:

> Oui, nombre par défaut, paramétrable dans db_info.xml. C'est un
> compromis à faire entre un besoin d'historique et un besoin de mémoire.
> Par ailleurs, c'est un objet SDXResults qui est stocké (celui-ci pointe
> sur un SDXQuery), ces deux objets ont des méthodes de sérialisation XML
> (toDOM()), si vous voulez les stocker sur disque, ce n'est pas très
> difficile à implanter.


On est d'accord :-)


> Personnellement, si j'avais besoin de récupérer les sessions en XSLT, je
> passerais peut-être par l'écriture d'un URIResolver. C'est la classe
> utilisée par le processeur XSLT pour obtenir quelque chose d'une URL, et
> on peut définir nos propres URIResolver qui pourraient être utilisés
> seulement pour certains patrons d'URL.


Sans aller dans auatnt de complexité, ne peut-on envisager d'ajouter un 
paramètre au servlet qui contiendrait l'ID de session et donc "d'émuler" 
 la transmission telle quelle se fait via une request HTTP en bonne et 
due forme ? Je vais regarder le code plus en détail et voir les 
implications de cette approche...


> Humm... Pas facile. 


Je ne te le fais pas dire :-)

> Je crois que la seule solution "facile" est...
> Complexe! Je m'explique. Si tu passes _tout_ les résultats de recherche
> (plutôt que 20 par pages par exemple), tu as en XSLT la connaissance
> nécessaire pour faire ta logique du point 4. De plus, tu peux implanter
> la logique de la navigation par page en XSLT, même si SDX le fait déjà.


Voici où j'en suis :

quand je passe sur le document j'ai bien le précieux sdx:navigation qui 
m'indique l'id de la requête (que j'ai appelée "baseQuery"). 
Malheureuseument, je n'ai pas la luceneQuery dedans.

Là, deux solutions sont possibles :
- soit je patche la taglib pour inclure la luceneQuery sans sdx:navigation
- soit je la transmets via un paramètre, mais là, je me retrouve avec 
des problèmes d'escaping du dit paramètre (je vais y revenir dans un 
autre post)... sans compter les problèmes potentiels liés à un paramètre 
trop long.

Quand bien même, cette solution me paraît sans issue car je n'ai pas 
d'API capable de me balancer telle quelle une luceneQuery à laquelle 
j'aurais concaténé mon critère de recherche supplémentaire (option 
apparemment choisie par Rui). En effet, le mise en minuscules me flingue 
cette approche :-)

Je pense donc que l'option de transmission de l'id de session me paraît 
être la moins mauvaise solution... à condition bien sûr que ma baseQuery 
ne soit pas flinguée au bout de la 4ème sous-requête. Il faudrait donc 
avoir la possibilité *de ne pas* stocker les requêtes intermédiaires et 
donc de ne pas faire avancer le compteur.

Qu'en pensez-vous ?

> La cache est en objet de session, donc propre à un utilisateur. Donc les
> autres utilisateurs n'ont aucune influence sur la cache sur la tienne.
> C'est au moins cela.


Toujours ça de pris, effectivement :-)


> C'est pour cette raison d'ailleurs qu'il faut faire attention aux
> besoins mémoire : s'il y a 20 000 sessions utilisateurs (elles durent au
> moins 30 minutes par défait, alors ça peut monter vite) et que chacun
> stocke 5 recherches, ça va tout de même paraître sur le serveur. Si on
> stocke jusqu'à 20 requêtes, ce sera potentiellement 4 fois plus de
> mémoire.


C'est pour cela qu'il faudra probablement un jour envisager un autre 
stockage qu'un arbre DOM particulièrement réputé pour sa consommation 
mémoire... Mais bon, on aura le temps d'en reparler...


--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden