Java 在EJB3中使用ThreadLocal变量的固有危险？

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

假设每个请求在完成后都会清理其ThreadLocal映射，那么将ThreadLocal变量与无状态会话bean一起使用会有任何风险吗？换句话说，是否存在两个请求同时访问同一线程的风险

有没有办法强制servlet在完成后清理ThreadLocal？我已经研究过拦截器，但我知道它们在EJB3上工作得很差，在不同的应用服务器上工作得也很好。还有别的办法吗

---

我建议不要在EJB容器中使用ThreadLocal。授权和身份验证是一个交叉问题，我个人会考虑使用类似AOP的东西（例如Spring security如何处理它）。

关于Martin的回答，值得注意的是Spring security本身默认使用ThreadLocal（），因此，如果您需要安全上下文在EJB调用中生存，我会谨慎使用它。当然，它不能跨远程调用工作；可能是本地的，但我不认为有任何保证

---

通常，在使用Spring安全性时，我避免使用EJB，而是使用Spring框架连接POJO中间层，并通过AOP提供事务划分等服务。安全上下文在整个中间层都可用，因为线程在整个调用中保持不变。

要回答我自己的问题，不，似乎没有任何安全性。如果我可以控制整个过程，使用threadlocal变量可能会起作用，但是如果我控制了整个过程，那么我可以使用CDI och JSP来保留请求局部变量

---

指向所有回答的人。

很有趣，但我不明白AOP如何提供我所需要的，即我如何在整个请求中共享一个值（如主题）？AOP在您需要的时候注入它-这是一个不同的范例，而不是自己手动处理它。请参阅以获取概述。正如OP中所述，在这种情况下，更改技术不是一个选项，我恐怕：/I对于这个问题，我只能使用EJB。