java - Inherent dangers of using ThreadLocal variables with EJB3? -


i'm experimenting solution authorization , authentication storing subject class in threadlocal map. design api, won't have access servlets involved, , need use ejb3 (so cdi not option). have few questions using threadlocal ejb3

  1. presuming each request cleans threadlocal map after it's done, there risk in using threadlocal variable stateless session beans? in other words, there risk 2 requests access same thread @ same time?

  2. is there way of enforcing servlets clean threadlocal after they're done? i've looked interceptors, i've understood work poorly ejb3, , work varyingly in different application servers. other way?

regarding martin's answer, it's worth noting spring security uses threadlocal anyway default (securitycontextholder), i'd cautious using if need security context survive across ejb invocations. won't work across remote invocations; might local, don't think there guarantees.

typically, when using spring security avoid ejb , use spring framework wiring pojo middle-tier , providing services transaction demarcation via aop. security context available throughout middle tier thread remains same across entire call.


Comments

Popular posts from this blog

asp.net - repeatedly call AddImageUrl(url) to assemble pdf document -

java - Android recognize cell phone with keyboard or not? -

iphone - How would you achieve a LED Scrolling effect? -