Utilisation de ThreadLocal pour gérer les données de session

Question

J'ai un doute sur l'utilisation de threadlocal dans la gestion des sessions. Il est ..

Dans Thread Local, le thread qui crée l'objet local thread a toujours accès à cet objet de session et seul ce thread peut modifier les données de l'objet session. Il peut y avoir plusieurs threads en cours d'exécution pour compléter une requête utilisateur unique. Alors, qu'en est-il de tous les autres threads qui participent pour compléter une requête utilisateur. Ils n'auront pas accès pour modifier l'objet de session, comme n'importe quel thread crée l'objet local Thread obtient son propre objet de session, ainsi les autres threads qui exécutent une requête utilisateur unique peuvent ne pas mettre à jour leurs données vers l'objet de session ils voulaient réellement. Je veux dire si thread-1 et thread-2 participent à la réalisation d'une requête utilisateur, mais thread-1 vient créer l'objet threadlocal, et thread-2 exécute d'autres codes dans le cadre de la requête, mais après thread-2 achèvement, il ne peut pas mettre à jour les données de session parce que seul tharead-1 a accès à la session car il a créé l'objet threadlocal.

Alors, comment réglons-nous ce problème? Allons-nous nous assurer qu'un seul thread participe à la demande d'un seul utilisateur? ou

Comment sommes-nous si sûrs que le thread qui crée l'objet threadlocal n'arrive qu'à mettre à jour les données de session associées à cette requête?

Answer 1

Eh bien d'abord, RTS (système en temps réel) doivent être distingués des systèmes haute performance. En temps RTS a été divisé en images et un morceau de logiciel a une ou plusieurs images qui leur sont allouées. Ce qui rend très prévisible quel système de tâches fonctionne à un moment donné et quelles sont les autres tâches qui s'exécutent en parallèle. Ainsi, l'aide à la conception permet d'éviter/de limiter la gestion des accès simultanés. Deuxièmement, les systèmes haute performance (quel que soit RTS ou non) ne dépendent pas nécessairement du multithreading pour la même raison que pour RTS: la gestion des accès concurrents et les structures de blocage sont plus précisément des goulots d'étranglement. Et le multithreading n'est pas la seule solution pour le traitement parallèle. Les fourches, les grilles de calcul et les versions ultérieures sont les plus performantes et offrent plus d'évolutivité, de stabilité, de robustesse, etc.

Ainsi, les environnements à un seul thread sont généralement basés sur une conception asynchrone. Vous divisez votre travail (c'est-à-dire le traitement des demandes) dans de petites structures sans attente/blocage. Tout l'attente/blocage (ou même l'informatique longue agressive) sont envoyés "quelque part" et notifier juste le processeur de demande une fois terminé. Dans ce cas, un thread peut traiter plusieurs requêtes pendant un seul traitement de requête (pas sûr d'être clair à ce stade ...)

Dans ce cas (et dans d'autres), vous ne pouvez pas utiliser la liaison locale au thread. Cependant, vous pouvez utiliser la "portée locale" pour partager une référence dans votre traitement:

Map<String, String> context = new LinkedHashMap<>(); 
context.put("id", "42"); 
taskQueue.add(() -> context.put("state", "action1")); 
taskQueue.add(() -> System.out.printf("%-10s > state=%s%n", context.get("id"), context.get("state"))); 

(en supposant taskQueue est Queue de Runnable)

Vous pouvez également enregistrer le contexte de la demande:

1. générer un "Unique Request Identifier" (la classe appropriée doit être UUID)
2. en utilisant une demande de stockage de contexte (peut être un simple ConcurrentMap) ou mo re stockage avancé tel que Key-Value Cache, Key-Value Store ou Document Store.
3. fixation « Demande unique Identifier » à toutes les actions liées demande-