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

[Martin Sévigny]

Bonjour,

> Cela veut dire que c'est bien le *serveur* qui :
> - stocke *en mémoire* les infos de session (les baseQuery 
> dans mon cas) ?
> - détruit les requêtes dès lors qu'il en a plus de 5 (nombre 
> par défaut) ?

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.

> > Le problème est que les servlets de recherche n'exploitent pas les
> > informations de session, contrairement à l'API XSP.
> 
> 
> Euh, là, je pers les pédales : mon servlet tourne, en XSP, ça tourne 
> aussi. C'est à la transformation (XSL) que ça ne tourne pas 
> car, l'appel 
> à document() ne semble transmettre aucune info de session, non ?

Ah bon, je suis allé trop vite. Je ne me rappelais pas que j'avais
implanté les informations de session dans la servlet.

Par ailleurs, l'appel à document() est géré par le processeur XSLT qui,
dans le cas de SDX, ouvre un connection à l'URL en question avec les
librairies Java. Et effectivement il n'utilise pas les informations de
session.

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.

Si cette classe a accès à l'environnement Tomcat, elle a accès à
l'environnement SDX, et (peut-être) aux sessions. Ce dernier point est à
vérifier.

> 1) SDX me permet de retrouver un jeu de résultats {A} à partir d'une 
> requête X.
> 
> 2) J'affiche un des membres de {A}.
> 
> 3) Celui-ci contient un lien (hypertexte) vers un document B.
> 
> 4) Voici la logique que je veux mettre en oeuvre à partir de là :
> 
> Si B est membre de {A}, je continue la navigation dans la requête : 
> passer au résulttat N (indice de B dans {A})
> Si B n'est pas membre de {A}, je préviens que l'utilisateur 
> est en train 
> de sortir de la requête.
> 
> D'où la baseQuery (la requête) et une requête secondaire sur 
> l'identifiant de B...

Humm... Pas facile. 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à.

> Il est clair que cette approche n'est pas bonne car, dès le 5ème lien 
> (et encore, à condition que je sois le seul utilisateur ?), 

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.

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.

A bientôt,

Martin Sévigny