目前我正在使用JSF请求作用域bean来完成我的所有CRUD操作。因为我确定你很可能知道Tomcat不提供容器管理的持久性，所以在我的CRUD请求bean中我使用EnityManagerFactory来获得enity manager的折叠。现在关于我选择使用请求作用域bean来完成这项任务的有效性，它可能会再次开始讨论，但我一直试图将它放在我给你链接的文章中读到的内容中特别是第一个和第二个。从我收集的内容来看，EclipseLink默认使用二级缓存来存储缓存实体。在ExlipseLink示例 - JPA Caching网站上，它说：
共享缓存在持久性单元（EntityManagerFactory或服务器）的持续时间内存在
现在不会让我的缓存实体在调用CRUD请求bean的过程中活一段时间，因为bean被销毁的时刻和EntityManagerFactory然后就是缓存。上面句子“EntityManagerFactory，或者服务器”的最后一部分让我感到困惑。在这种情况下，或服务器究竟是什么意思，以及如何控制它。如果我使用@Cache注释并设置适当数量的expire属性，那么无论我的EntityManagerFactory是否已经被销毁，它都能完成这项工作并保持存储在服务器L2缓存上的实体吗？
我知道有很多事情要做，每个应用程序都有特定的要求。从我的角度来看，配置L2缓存可能是最理想的选择（如果不仅仅是Tomcat）选项。引用您的第一个链接：
L2缓存的优点是：
- 避免已加载实体的数据库访问
- 阅读频繁访问的未修改实体的速度更快
L2缓存的缺点是：
- 大量对象的内存消耗
- 更新对象的陈旧数据
- 写入并发（乐观锁定异常或悲观锁定）
- 频繁或同时更新的实体的可扩展性不佳
您应该为以下实体配置L2缓存：
- 经常阅读
- 不经常修改
- 如果陈旧
则不重要
以上几乎所有要点都适用于我的应用。除此之外，其核心是持续不断地阅读实体并在网站上显示它们（该应用程序将作为列出属性的门户）。在应用程序中还有一个小型购物车，但销售的产品不是有形物品，而是作为库存而是服务。在这种情况下，陈旧的实体没有问题，所以我认为，并不是并发性，因为产品（这里的服务）将永远不会被写入。因此，实体将被经常阅读，并且它们将不经常修改（并且那些被修改的不是推车的一部分，甚至那些很少被修改）因此如果陈旧则不重要。最后，前两点似乎正是我所需要的，即避免对已经加载的实体的数据库访问以及快速读取频繁访问的未修改的enteties。但有一点缺点仍然让我感到担忧：大量物体的内存消耗。这不是我原来的问题吗？
我目前的理解是有两种选择，其中只有一种适用于我的情况：
为了能够将长期缓存的作业委托给持久层，而不是我需要访问PersistenceContext并创建会话范围的bean并设置PersistenceContextType.EXTENDED。 （此选项不适用于我，无法访问PersistenceContext）。
在实体上配置L2 @Cache注释，或者像上面的选项1中那样创建一个将处理长期缓存的会话范围bean。但这些不仅仅是回到原来的问题吗？
我真的很想听听你的意见，看看你认为什么是合理的方法，或者你在以前的项目中如何接近它。哦，还有一件事，只是为了确认..当用@Cache注释一个实体时，所有链接的实体都将被缓存，所以我不需要注释所有这些实体？
所有的评论和指示再次受到赞赏。
谢谢你回答..当你说
时“在Tomcat中，你最好有一个静态管理器，在服务器的持续时间内保存在EntityManagerFactory上。”
这是否意味着我可以在应用程序范围内声明并初始化静态EntityManagerFactory字段，以便以后所有bean在应用程序的整个生命周期中都使用它？
答案 0 :(得分：0)
EclipseLink默认使用共享缓存。这是从EntityManagerFactory访问的所有EntityManage共享的。您无需执行任何操作来启用缓存。
通常，您不希望每个请求创建一个新的EntityManagerFactory，只需要一个新的EntityManager。创建一个新的EntityManagerFactory是非常昂贵的，所以不是一个好主意，甚至忽略缓存（它有自己的连接池，必须初始化元数据等）。
在Tomcat中，您最好有一些静态管理器，它在服务器的持续时间内保留在EntityManagerFactory上。永远不要关闭它，或者在Servlet被破坏时关闭它。