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

[Pierrick Brihaye]

Je me réponds à moi-même. La nuit a porté conseil :-)

Pierrick Brihaye wrote:

> Eh bien, la *même* requête cette fois-ci dans une XSL (avec un document(), bien 
> sûr), me renvoie un résultat (alors que je n'en veux pas). Il est intéressant 
> de voir comment elle a été interprétée :
> c'est à dire que, probablement, SDX n'a pas trouvé la fameuse "q27" dans l'info de session. Je tiens à préciser que les 
> tentatives de réutilisation de "q27" ont été nommée respectivement "q28" et "q29" (car SDX a, par 
> défaut, un cache de 5 requêtes). A moins d'un bug Saxon qui flinguerait le paramètre "bq" (pourquoi lui plutôt qu'un 
> autre ?), je me demande vraiment ce qui se passe...


Bon, c'est simple. Quand on interroge le servlet via son navigateur, 
celui-ci dispose de l'info de session dans ses cookies : il peut donc 
l'envoyer au serveur et dire "je veux que tu fasses ça à partir de la 
"q27" que voici".

En revanche, côté serveur (celui qui traite la XSL), la "q27", il ne la 
connaît pas, ou plutôt, il ne la connaît plus... A moins que je ne me 
trompe, SDX ne stocke aucune des infos qu'il envoie aux clients.

Je pense que c'est là une lacune majeure dans l'implémentation actuelle. 
Implémenter un caching au niveau serveur permettrait entre autres 
d'optimiser les échanges pour ne renvoyer que ce qui est demandé (pages 
de 20 résultats p.e.), d'où un gain de performance certain, sutout pour 
les utilisateurs qui demandent que les documents soient renvyés dans les 
résultats de requêtes ;-)

Est-ce que SDX 2 prévoit un tel mécanisme ? Comment le résoudre : via 
des allocations en mémoire (difficilement concevable), en XML,  via une 
ou des tables de BD ?

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