Comment supprimer des données de session à un intervalle de temps régulier, toutes les heures?

Je ne sais pas grand chose à propos de quartz, mais c'est ce que je ferais dans votre situation: Printemps 3.2, non? Dans votre contexte de candidature:

class SessionCleaner{
        @Autowired
        private MySessionDataBean sessionData;

        @Scheduled(fixedRate=3600000)
        public void clearSession(){
            sessionData.getList().clear();//something like that    
        }
}

Commentaires

Félicitations à l'aide des jetons pour empêcher les soubmits ("introduire la synchronisation de jeton de synchronisation" à partir des motifs J2EE du livre J2EE). : ^) p>

Quartz est précieux pour une planification compliquée ou précise. Mais vos besoins n'ont pas besoin de quartz. Pourrait être plus utile d'apprendre CDI, Java.Util.Timer, planchedexecutor et / ou EJB minuteries. P>

Si vous utilisez un planificateur, comme vous le mentionnez, il est bon d'avoir un planificateur Singleton partagé par tous les utilisateurs, plutôt que d'avoir une instance de planificateur et de thread par session utilisateur. P>

Soyez prudent si vous stockez déjà des références à httpsession ou de le transmettre en tant que paramètre. Stockage des références empêche la collecte des ordures lorsque la session est complète - provoquant une fuite de mémoire (gros?). Les tentatives de nettoyage des références à l'aide de HttpsPessionsListener et d'autres astuces, peuvent ne pas travailler et sont désordonnés. Passer httppsession à des méthodes sous forme de paramètre qui les rend artificiellement dépendants artificiellement du récipient de servlet et de tester difficiles à un appareil, car vous devez faire une simulation d'objets httpsession complexes. Il est plus propre d'envelopper toutes les données de session dans un objet Singular ObjectSetSetState - Conservez des références à ce em> dans vos variables d'instance de session et d'objet. Ceci est également connu sous le nom de modèle d'objet contexteur - c'est-à-dire que vous stockez toutes vos données scopées dans un / quelques objets contextuels Pojo, indépendant des classes de protocole HTTP. P>

Réponse H2>

Je suggère deux solutions alternatives à votre problème: p>

1. Utilisez un Java.Util.Timer Code> Singleton Instance P>

   Vous pouvez remplacer java.util.timer code> (introduit dans Java SE 1.3) avec planchedexecuteur code> (introduit dans Java SE 5) pour une solution presque identique. p>

   Ceci est disponible avec le JVM. Il ne nécessite aucune configuration JAR et aucune configuration. Vous appelez timertask.schedule code>, en passant dans un TIMERTASK code> instance. Lorsque la planification est due, timertask.run code> est appelé. Vous supprimez les tâches planifiées via timertask.cancel code> et timertask.purge code> qui libère la mémoire utilisée. p>

   Vous codez le TIMERTASK code>, y compris son constructeur et vous créez une nouvelle instance et transmettez-la à la méthode de planification, ce qui signifie que vous pouvez stocker des références de données ou d'objet dont vous avez besoin dans le TIMERTASK ; Vous pouvez conserver une référence à elle et appelez les méthodes de réglage à tout moment plus tard. p>

   Je vous suggère de créer deux singletons globaux: A Minuterie code> instance et a TIMERTASK code> instance. Dans votre instance Custom TIMERTASK CODE>, conservez une liste de toutes les sessions utilisateur (sous forme POJO comme usersessionState CODE> ou Spring / CDI Bean, non sous la forme de httpsession code >). Ajoutez deux méthodes à cette classe: addsessionObject code> et reploisessionObject code>, avec un paramètre de usersessionState code> ou similaire. Dans la méthode TIMERTASK.RUN CODE>, itérale via l'ensemble de usersessionState code> et effacer les données. P>

   Créer une personnalisation HttpSspessionListener - de SessionCreated, mettez une nouvelle instance utilisateurState dans la session et appelez Timerask.Ajoutersession. De SéanceDestroyed, appelez timerask.removeUsersession. P>

   Appeler le Singleton Global-Scoped Singleton Timer.Schedule CODE> Pour planifier l'instance TIMERTASK pour effacer le contenu de la référence Session-Scoped. P> LI>

2. Utilisez la liste de jetons avec la taille plafonnée (pas de nettoyage) p>

   Ne nettoyez pas les jetons basés sur le temps écoulé. Au lieu de restreindre la taille de la liste (par exemple 25 jetons) et stockez les jetons les plus récemment générés. P>

   C'est probablement la solution la plus simple. Lorsque vous ajoutez un élément à la liste, vérifiez si vous avez dépassé la taille maximale, le cas échéant et insérez à partir de l'indice le plus ancien de la liste: P>

   if (++putIndex > maxSize) {
       putIndex = 0;
   }
   list.put(putIndex, newElement);
   

Mon idée serait quelque chose comme:

Version courte:

1. Changer l'intervalle de tâche à 1 minute;
2. ajout désastablez méthode sur sessionTokenservice qui sera invoqué chaque minute mais ne nettoie pas la liste des jetons s'il est vraiment nécessaire (dans ce cas, la décision est effectuée en fonction de le temps).

   Version détaillée:

   Votre tâche planifiée s'exécutera chaque minute appelera la méthode non enregistrée mise en œuvre par sessionToken . La mise en œuvre de la méthode vérifiera la dernière liste de jetons de jeton de la dernière fois était propre et invoquer désattalltokens s'il était il y a une heure.

   mais afin de l'invoquer dans chaque session Scoped SessionTokenService Vous aurez besoin de la liste des SessionTokenService existant S, qui pourrait être réalisé en l'enregistrant au moment de la création au service qui le nettoiera (vous utiliserez ici un FaibleHashMap < / Code> Pour éviter les références difficiles, cela éviterait les objets à collecter par le collecteur des ordures).

   La mise en œuvre serait une chose comme ceci:

   Jetons de session: < / forte>

   interface: xxx

   implémentation: xxx

   ralligère de jeton de session:

   interface: xxx

   implémentation: xxx

   Dans ce cas, vous utiliserez la fonction de tâche entraînée de l'annotation Du printemps: xxx

   de mon point de vue serait une solution simple et bonne.

   EDIT

   avec ceci a PPROCH Vous êtes plus ou moins enregistrant le sessionToken au fichier lorsque le ressort se termine la configuration du haricot et le retirez lorsque le ressort détruit le haricot, cela se fait lorsque la session est terminée.