Discussion :

[stof]

Bonjour,

J'ai un écran qui contient diverses données.
-on coche les lignes souhaitées
-on crée un fichier Excel et on change enfin le statut des données puis on rafraîchit la page.

Risque : 2 sessions peuvent tenter de faire la même demande avant le changement de statut des données (sinon la question ne se poserait pas, il suffirait de commencer à vérifier le statut en base)

A] Une des solutions envisagées :
Remplacer

Code :

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

public ActionForward myAction

par

Code :

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

public synchronized ActionForward myAction

Question1 : là, j'ai pas tout compris donc je compte sur vous pour m'expliquer, mais on m'a dit que si je fais ça, non seulement j'empêche les autres sessions/utilisateurs de rentrer en même temps dans la fonction (ce qui résoud éventuellement mon potentiel problème d'accès concurrents même si c'est idiot de bloquer quand c'est des lignes différentes) mais je les empêche aussi d'exécuter n'importe quelle autre fonction de ma classe Action. On m'a parlé aussi de comportement différent entre Struts1 et Struts2.




B]La solution qui vient d'être mise en place :
Insérer en début de fonction un bloc synchronized

Code :

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

1
2
3
synchronized (syncCkecker) {
//Traitements expliqués ci-dessous
}

qui va lire la liste mise dans le context de la servlet

Code :

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

List<Integer> servList = (List<Integer>)request.getSession().getServletContext().getAttribute("myList");

On teste si la nouvelle liste demandée contient des éléments communs
a)OUI --> erreur affichée sur la page
b)NON -->on lui ajoute les éléments de la nouvelle liste demandée

Puis la fonction continue ses traitements entourée par un try...catch...finally où dans le finally on purge la liste enregistrée dans le contexte de la servlet des ordres qu'on a ajouté au début.
Question2 :Ca vous semble la meilleure solution?

[stof]

Ca doit donc être la meilleure solution

[fxrobin]

Pourquoi ne pas créer le fichier EXCEL simplement en mémoire ?

En effet, une servlet peut très bien renvoyer un fichier XLS dynamiquement sans que celui-ci ne soit créé physiquement sur le disque (ce qui est d'ailleurs une très mauvaise pratique)

Ca t'éviterait tous ces problèmes de synchronisation.

Enfin, si le XLS est très volumineux, tu peux songer éventuellement à le mettre en cache, partagé ou non, avec ehcache par exemple.

[stof]

Pourquoi ne pas créer le fichier EXCEL simplement en mémoire ?

Pour être sûr de garder une trace de l'action notamment.

Ca t'éviterait tous ces problèmes de synchronisation.

Pourquoi? Même "dynamiquement" il faut le temps de le construire et pendant ce temps on peut avoir une demande similaire en parallèle.

[fxrobin]

Pourquoi? Même "dynamiquement" il faut le temps de le construire et pendant ce temps on peut avoir une demande similaire en parallèle.

bah non parce que tu le construis dynamiquement pour 1 session utilisateur.
La portée de la variable est soit "request" soit "session", donc pas de conflit entre utilisateurs.

Pour l'avoir fait des dizaines de fois sur des projets qui génèrent des excels et des PDF accessibles "simultanément" c'est ce qu'il faut faire.

Après si tu veux conservé ce qui a été généré, fais le après que la réponse ait été envoyée et fais le en synchronized si par hasard c'est le même nom de fichier ... mais encore une fois, c'est vraiment pas bien comme solution. Tu vas l'écrire où ton fichier ? dans la webapp ? très mauvaise idée, car en cas de re-déploiement / suppression de l'appli, tu perds aussi ton fichier.

Au pire Si tu veux conserver pour de la traçabilité, conserve le flux en base de donnée avec un BLOB, où encore envoie le flux généré vers un serveur FTP ... mais surtout pas dans la webapp.

[fxrobin]

Pour être sûr de garder une trace de l'action notamment

Trace ? quelle trace d'ailleurs ? avec ton système tu n'auras que le XLS généré par le dernier utilisateur : c'est pas vraiment une trace