java – ThreadLocal是否优于HttpServletRequest.setAttribute(“key”,“value”)?

前端之家收集整理的这篇文章主要介绍了java – ThreadLocal是否优于HttpServletRequest.setAttribute(“key”,“value”)?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
servlet规范(参见我之前的问题)保证相同的线程将执行所有过滤器和关联的Servlet.鉴于此,如果有使用ThreadLocal的选项(假设您正确清理),我认为使用HttpServletRequest.setAttribute传递数据没有任何用处.我觉得使用ThreadLocal有两个好处:类型安全性和更好的性能,因为没有使用字符串键或映射(除了可能通过(非字符串)线程id进入线程集合).

有人可以确认我是否正确所以我可以继续放弃setAttribute?

解决方法

Is ThreadLocal preferable to HttpServletRequest.setAttribute(“key”,“value”)?

取决于具体的功能要求.

例如,JSF将FacesContext存储在ThreadLocal中.这使您可以访问所有JSF工件,包括由FacesServlet执行的代码中的任何位置的“原始”HttpServletRequest和HttpServletResponse,例如托管bean.大多数其他基于Java的MVC框架都遵循相同的示例.

根据你的评论,

I primarily need to transport the User and EntityManager objects from the user and database Filters to the Servlet. I also find that these are frequently and unexpectedly needed in code further down the line and I am tempted to use them well beyond the Servlet (i. e. in nested code called by doGet). I feel there may be a better way for deeper code – suggestions?

至于我假设这是一个会话属性的User示例,我宁愿采用与JSF相同的方法.创建ThreadLocal< Context> Context是您的自定义包装类,包含对当前HttpServletRequest的引用,也可能是HttpServletResponse,以便您可以在代码中的任何位置访问它们.如有必要,可以直接从Context类中提供方便的方法获取用户.

至于EntityManager示例,您可以遵循相同的方法,但我个人不会将它放在相同的ThreadLocal< Context>中,而是一个不同的方法.或者,更好的是,只需从服务层中的JNDI获取它,这将允许您对事务进行更细粒度的控制.无论如何,请确保您正确处理提交/关闭.从容器中接管持久性和事务管理应该非常小心.我真的重新考虑使用现有的和设计良好的API /框架(如EJB / JPA)的厌恶,否则你将冒险完全浪费时间重新发明所有已经标准化的API和东西.

也可以看看:

> Retrieving Web Session from a POJO Outside the Web Container
> Design Patterns web based applications

猜你在找的Java相关文章