sessions genre php en j2ee? - Page 1

yop,

bon, imaginez un webservice. j'en connais pas encore grand chose, hein.

des gens peuvent appellent des méthodes, OK, ça, j'y arrive maintenant.

mais un webservice c'est stateless , du coup il oublie tout entre deux appels.

est ce qu'on a un mécanisme équivalent aux sessions de php pour se souvenir des gens qui s'y connectent? j'avais vu trainer ça dans tomcat (comme ça: http://www.javafr.com/forum/sujet-CMT-TRAVAILLER-AVEC-SESSION-J2EE_1196785.aspx ), mais dans glassfish je sais pas si ça marche.

pour le moment j'ai fait un manager à la main. une méthode open_session() renvoie un ID, et on utilise l'identifiant retourné dans tous les appels suivants.
et (c'est là que ça se corse) je démarre un thread de nettoyage qui vire les vieilles sessions en tâche de fond.

mais savez vous si on peut hooker la suppression d'une appli? Pour le moment mon thread s'arrête pas quand on vire l'appli, donc ça fout le binze

merci à ceux qui bossent là dedans pour les quelques secondes qu'ils voudront bien me consacrer. je suis sur que c'est super évident , et que j'y connais rien.

En fait on peut garder une session avec les webservices en réglant je ne sais plus trop quoi... Je ne suis pas certain que ça soit complètement standard, mais je sais que ça se définit facilement avec une simple annotation si on fait un webservice dot net en c#, et que j'avais réussi à activer le support des sessions en m'y connectant depuis un programme JAVA via la lib Axis)

PS : et par la suite j'avais aussi codé un webservice en java, qui supportait les sessions également. Je regarderai demain avec quoi je l'avais codé... Je ne m'en rappelle même plus (c'était juste du prototypage)
(c'était peut-être bien glassfish v3 prelude, mais j'ai un doute)

là je suis aussi en gf3

apparemment ce dont tu parles est probablement l'annotation @Stateful, dont je vois pas trop quel est son effet.

mais apparemment tout le monde déteste les ws stateful parce que ça pète la scalabilité de l'appli: voir [1 ]. Tu peux pas ajouter des serveurs à l'envie et traiter plus de requêtes, ton client est lié au serveur.

Du coup ça confirme que je commençais bien avec ma gestion manuelle, et on en revient au: comment tuer un thread quand je undeploy mon application
parce que là c'est la cata, a chaque deploy il démarre un nouveau thread, et tu devines la suite

[1 ]
http://stackoverflow.com/questions/1009863/how-good-necessary-are-stateful-web-services

session et webservice effectivement c'est pas recommandé.
Glassfish doit savoir géré ca de base, mais je connais pas glassfish

A propos du thread, y'a le shutdown hook:
http://download-llnw.oracle.com/javase/1.4.2/docs/guide/lang/hook-design.html
Sinon y'a bien plus simple, fait de ton thread un daemon: mythread.setDaemon(true)
Mais y'a un truc qui méchappe. Et je pense que je répond pas à ta question en fait En fait tu redéploie ton server sans redémarrer la jvm ?

(nafout que ce soit pas recommandé, ça me servirait grave à rien sans session. L'alternative c'est quoi? filer un login/mot de passe dans chaque appel à l'API distante?

sans redémarrer la vm: oui, grace a netbeans
le shutdown hook de la VM, je connais, mais ça me donc servirait à rien.

le thread en question ne fait que purger les vieilles sessions.
je pourrais m'en passer comment? en appelant le purgeage à chaque nouvelle création de session? mouais.

Et si chaque instance de session démarre un thread avec un timeout d'inactivité ? Quand le temps est passé, chaque thread se termine tout seul.

pas con en effet. Mais une VM normale peut gérer combien de threads?

Parce que si on me fait un DDOS qui ouvre des centaines de sessions, le serveur va avoir super mal, même si je met un timeout de 2 secondes tant que l'authentification n'est pas complète sur cette session.

Il faudra une authentification genre SSL qui encapsule tout le service, en fait.

C'est ce que j'ai fait il y a quelques jours en fait (une classe Session, pas une attaque DOS )

Pour le nombre de threads maxi, j'en sais rien, désolé. Je suppose que tu as de la marge... D'ailleurs c'est pas aussi violent qu'un processus, quand même (enfin j'imagine )
Et puis c'est pas difficile à tester

(De toute façon, en cas d'attaque DOS, ton serveur va souffrir... Donc ça ou autre chose... )

c'est pas faux

je viens d'implémenter le coup du thread par session, ça fait le job nickel, merci

De rien

Pfff, je suis blasé...
écran bleu, voici mon source après reboot :

Source d'aujourd'hui, donc pas de sauvegarde, bien sûr \o/ (et le .class a disparu, donc pas de décompilation possible)
J'ai vérifié avec un éditeur hexa, il n'y a que des zéros dans le fichier
Bon, il n'était pas trop gros, ni trop critique, mais bon... Il faudrait que je trouve le matériel qui me provoque ces écrans bleus



PS : oué, c'est légèrement hs, mais c'est du java, quand même
Pas le courage de créer un topic

c'est intéressant

T'as pas de sauvegarde automatiques dans ton ide ?

Je viens d'en avoir deux consécutifs, il y a vraiment un problème, là...
Folco > ben le fichier était enregistré, mais visiblement il y a eu un petit problème... Et j'ai eu le temps d'apercevoir un message du genre "make sur you have enough available disk space" sur le BSOD
D'ordinaire, c'est plutôt du genre "non paged area". On va bien voir... (J'ai finalement décoché le reboot automatique pour avoir le temps de lire les BSOD.)

Bon, là je n'ai rien perdu au moins



PS : quand j'y pense, non, il n'y pas de sauvegarde automatique dans eclipse... Ou alors je ne l'ai jamais activée ou remarquée

Probably caused by : ntkrnlmp.exehum hum...

à lire demain :
http://social.answers.microsoft.com/Forums/fr-FR/w7repairfr/thread/d34c205b-e5fa-4c59-8398-1c75f5284302
http://support.microsoft.com/?scid=kb%3Ben-us%3B842465&x=7&y=14

C'est quoi comme système de fichiers? Du NTFS?

Oui.

En fait, tout ça me rappelle l'époque de Millennium #nostalgie#

En french : http://support.microsoft.com/kb/842465/fr

Penpen > J'adore ta façon de détourner des topics et de créer une certaine utilité égoïste un peu n'importe où, avec tact et élégance

Ouah, recevoir un compliment sur le tact par Nil, ça vaut son pesant d'or

au fait j'ai trouvé:

@PostConstruct
public void postConstruct() {
//appelé au premier appel soap du service
}

@PreDestroy
public void preDestroy() {
//appelé au un-déploiement ou au re-déploiement
}


ça fait ce que ça dit

du coup j'ai plus qu'un thread ramasse miettes qui vire les vieilles sessions, au lieu d'un thread par session, ce qui est quand même assez lourd.

(merci, au fait )

de rieng