Attribut session

Attention à ne pas confondre. Les cookies sont gérés côté client, qui peut s'il le souhaite les supprimer voire les interdire. La session elle est cotée serveur, le client ne peux pas savoir ce que tu mets dedans et combien de temps tu le garde en mémoire (tout au plus le client peut connaître son sessionid). L'intérêt de la session est de pouvoir mettre des données en cache pour ne pas avoir à tout recalculer à chaque requête. Il serait par exemple dommage si tu donnes le login/password d'aller à chaque requête vérifier que le password est bon alors qu'il suffit de le faire une fois et d'enregistrer l'information dans la session.

Remarque : les attributs du scope request ne sont vraiment utile que pour passer d'une technologie à l'autre (devenant des variables globales pour les jsp par exemple), mais comme elles sont effacées dès la réponse envoyée on ne peux pas s'en servir pour suivre les requêtes successives de l'utilisateur.
Le scope context est plus là pour lier les sessions entre elles, par exemple pour savoir quels sont les autres utilisateurs connectés (autres sessions actives).

j'ai bien compris maintenant la différence entre les cookies et les sessions merci :)
si c'est possible tu peux m'explique la notion d'attribut pour les sessions et les contexts (dans le cas de servlet et non jsp ) ! le faite de faire par exemple :

protected void doPost(HttpServletRequest request,HttpServletResponse response)  {
		response.setContentType("text/html");
		PrintWriter out = response.getWriter();
		HttpSession session = request.getSession();
		ArrayList<Etudiant> etud = (ArrayList<Etudiant>) session
				.getAttribute("NoteEtud");
                 if (etud == null) {
			etud = new ArrayList<Etudiant>();
			session.setAttribute("NoteEtud", etud);
		}

& merci une autre fois :)

"dans le cas de servlet et non jsp"
C'est la même chose ! Les fichiers .jsp sont compilés en servlet lorsqu'ils sont chargés par le serveur. C'est juste un raccourci d'écriture pour éviter d'avoir à manipuler un grand nombre de méthodes out.write de get/setAttribute, etc.

Dans ton exemple, tu as un fait une requête POST, grâce à l'objet request tu peux récupérer la session de l'utilisateur qui contient une Map<String,Object> comme je l'expliquais hier.

En faisant getAttribute("NoteEtud") tu récupères dans la Map l'Object enregistré avec le String "NoteEtud".
Si ça te renvoie null c'est que l'objet n'existait pas. Cela arrivera généralement lors de la première requête, car la session venant tout juste d'être créée, sa Map est vide.
C'est pour cela que tu as un test if(etud==null), cela permet de savoir si c'est la première fois que tu exécutes ce code pour la requête. Dans ce cas, tu initialises une liste vide d'étudiant, que tu ajoutes à la session.
Ainsi, lors de la prochaine requête POST traitée avec cette servlet, si la session est toujours valide, tu n'auras plus null, mais la liste que tu viens de créer.

Tu peux donc ajouter des étudiants dans ta liste au fur et à mesure des requêtes. Mais cette liste disparaitra une fois la session de l'utilisateur terminée. De plus si deux utilisateurs différents se connectent en même temps, comme chacun a sa propre session ils auront alors tous les deux une liste d'étudiants différente, chacun la sienne pour la session.

Si tu veux partager la liste des étudiants pour qu'elles soient communes à toutes les sessions, il faut alors enregistrer la liste non pas dans une session particulière d'un utilisateur, mais dans le contexte commun à toutes les servlets. Le fonctionnement est exactement le même, il s'agit d'une Map<String,Object> que tu manipules avec get/setAttribute.

HttpSession session = request.getSession();
ServletContext context = session.getServletContext();
ArrayList<Etudiant> etud = (ArrayList<Etudiant>) context.getAttribute("NoteEtud");
if (etud == null) {
    etud = new ArrayList<Etudiant>();
    context.setAttribute("NoteEtud", etud);
}

Attention à bien gérer les accès concurrents aux objets dans le context, et dans une moindre mesure dans la session. Si deux requêtes sont traitées exactement en même temps, il faut que le résultat soit toujours identique à celui que tu aurais du obtenir si tu avais traité les requêtes l'une après l'autre. Or avec le partage de données il est possible de se retrouver dans des cas où tu vas faire un setAttribute en fonction de la valeur getAttribute que tu as récupéré, mais qu'entre le moment où tu fais ton get et ton set, un deuxième utilisateur fasse la même chose, en récupérant la même valeur de get au lieu de considérer la valeur après le set.

Exemple (pseudo code)

int n = get("n");
set("n", n+1);

Les deux requêtes sont traitées en parallèle, la première fait un get("n") et récupère 0, la deuxième fait un get("n") et récupères 0, la première fait un set("n",1) et la deuxième fait aussi un set("n",1). Or le bon résultat serait d'avoir n=2 à la fin vu que deux requêtes ont demandés à faire +1 sur une valeur de 0 au départ.

vos informations sont très pertinentes merci beaucoup kx :)