ThreadLocal для управления данными сеанса

Question

У меня возникло сомнение в использовании потоков в управлении сеансами. Это ...

В потоке Локальный, который когда-либо поток, который создает локальный объект потока, имеет доступ к этому объекту сеанса, и только этот поток может изменять данные объекта сеанса. Для завершения одного запроса пользователя может быть много потоков. Итак, как насчет всех других потоков, которые участвуют в заполнении одного запроса пользователя.

Они не получат доступ к изменению объекта сеанса, так как любой поток создает локальный объект Thread, получает свой собственный объект сеанса, поэтому другие потоки, которые запускаются для завершения одного пользовательского запроса, могут не обновлять свои данные до объекта сеанса, к которому они действительно хотели.

Я имею в виду, если thread-1 и thread-2 участвуют в заполнении пользовательского запроса, но thread-1 приходит для создания объекта threadlocal, а thread-2 выполняет другие коды как часть запроса, но после thread-2 завершение, он не может обновить данные сеанса, потому что только tharead-1 имеет доступ к сеансу, так как он создал объект threadlocal.

Итак, как мы решаем эту проблему.

Мы убеждаемся, что только один поток участвует в заполнении запроса одиночных пользователей? или

Как мы уверены, что какая-либо нить, которая создает объект threadlocal, подходит только для обновления данных сеанса, связанных с этим запросом?

Answer 1

Ну, во-первых, RTS (система реального времени) следует отличать от высокопроизводительных систем. В RTS время было разделено на фреймы, а часть программного обеспечения имеет один или несколько фреймов, выделенных для них. Это делает очень предсказуемым, какая система задач выполняет в данный момент времени, а также какие другие задачи выполняются параллельно. Таким образом, дизайн помогает избежать/ограничения управления параллелизмом.

Во-вторых, высокопроизводительные системы (независимо от RTS или нет) не обязательно полагаются на многопоточность по той же причине, что и для RTS: управление параллелизмом и блокирование структуры более точно являются узкими местами. И многопоточность - не единственное решение для параллельной обработки. Вилки, грид-вычисления и четкие работы великолепны и обеспечивают большую масштабируемость, стабильность, надежность и т. Д.

Таким образом, среды с одним потоком обычно основаны на асинхронном дизайне. Вы разделяете свою работу (т.е. обработку запроса) в небольших структурах, не ожидающих/блокирующих. Все ожидающие/блокирующие (или даже агрессивные длинные вычисления) отправляются «где-то» и просто уведомляют процессор запросов по завершении. В этом случае один поток может обрабатывать многие запросы во время обработки одного запроса (не обязательно быть ясным в этот момент ...)

В таких (и некоторых других) случаях вы не можете использовать привязку к потоку. Тем не менее, вы можете использовать «локальную область», чтобы поделиться ссылкой через вашу обработку:

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"))); 

(при условии, taskQueue является Queue из Runnable)

Вы также можете сохранить контекст запроса по:

1. генерируя «уникальный идентификатор запроса» (подходящий класс должен быть UUID)
2. с использованием хранилища контекста запроса (может быть простым ConcurrentMap) или mo переработанное хранилище, такое как кеш-ключ, хранилище ключей или хранилище документов.
3. прикрепление «Уникальный идентификатор запроса» для всех запросов переплете действий