Использование ThreadLocal для управления данными сеанса

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

В Thread Local любой поток, который создает локальный объект потока, имеет доступ к этому объекту сеанса, и только этот поток может изменять данные объекта сеанса. Для выполнения одного пользовательского запроса может быть запущено много потоков. А как насчет всех других потоков, участвующих в выполнении одного пользовательского запроса?

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

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

Итак, как мы решаем этот вопрос.

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

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


java session-management thread-local
person santhosh    schedule 12.10.2015    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Во-первых, 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) или более расширенное хранилище, такое как кэш-память "ключ-значение", хранилище "ключ-значение" или хранилище документов.
  3. прикрепление «Уникального идентификатора запроса» ко всем действиям, связанным с запросом
person LoganMzz    schedule 12.10.2015
comment
На него уже ответили. Не используйте хранилище с привязкой к потоку, но с привязкой к запросу. Это нельзя сделать в локальной области, например, в моем примере кода, или с использованием идентификатора запроса и API-интерфейса хранилища, такого как объяснение в моем редактировании (последний абзац после примера кода). Позвольте мне, какие дополнительные детали вы должны быть удовлетворены. - person LoganMzz; 13.10.2015