使用ThreadLocal变量与EJB3的内在危险？

Question

我正在通过在ThreadLocal地图中存储主题类来尝试授权和身份验证的解决方案。该设计是针对API的，因此我无法访问所涉及的servlet，并且我需要使用EJB3（因此CDI不是一个选项）。我有一些关于将ThreadLocal与EJB3一起使用的问题

1. 假设每个请求在完成后清除其ThreadLocal映射，是否有使用无状态会话bean的ThreadLocal变量的风险？换句话说，两个请求是否有同时访问同一个线程的风险？

2. 有没有办法强制servlet在完成后清理ThreadLocal？我已经研究过拦截器了，但是我知道它们与EJB3的工作效果很差，并且在不同的应用服务器上工作得很好。还有其他方法吗？

Answer 1

关于Martin的回答，值得注意的是Spring Security本身默认使用ThreadLocal（SecurityContextHolder），所以如果你需要安全上下文来跨EJB调用生存，我会谨慎使用它。当然，它不适用于远程调用;它可能与当地有关，但我认为没有任何保证。

通常，在使用Spring Security时，我避免使用EJB并使用Spring Framework连接POJO中间层，并通过AOP提供事务划分等服务。然后，整个中间层可以使用安全上下文，因为整个调用中的线程保持不变。

Answer 2

我建议不要在EJB容器中使用ThreadLocal。授权和身份验证是一个贯穿各领域的问题，我个人会考虑使用像AOP这样的东西（例如Spring Spring如何处理它）。

Answer 3

回答我自己的问题，不，看似没有任何安全性。如果我控制整个过程，使用threadlocal变量可能会有效，但如果我这样做，那么我可以使用CDI och JSP来保持请求局部变量。

指向所有回答的人。