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
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?
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
Post a Comment