解除引用的休眠 (JPA) 实体会发生什么情况？
在我正在从事的一个项目中，我们有一个 EJB 后端，各种客户端远程连接（即 Web 层、Web 服务层等）。客户端位于另一台计算机上，并且可以位于另一个数据中心中，因此前端和后端永远不会位于同一应用程序服务器中。
后端分层如下：
SLSB <->服务层对象<-> DAO
所有对象都是 spring 管理的，除了 SLSB。事件链如下：
初始化：
- 实体管理器注入 DAO
- DAO 注入服务对象
- 服务对象注入 SL EJB
- SLSB 仅提供远程接口 所有对象都是单例和无状态
请求/响应：
在 EJB 上调用的方法、委托给服务对象、使用 DAO、返回 DTO
DAO 封装了 JPA 实体上的所有查询操作。没有 JPA 实体会渗透到服务层。服务层界定事务。
一旦请求/响应生命周期在此架构中完成，JPA 实体会发生什么？服务层是否应该尝试缓存实体，或者这是休眠的工作？
欢迎对此架构提出任何评论。
谢谢比尔沃斯
-
In a project i am working on, we have an EJB backend where various clients connect remotely (i.e. Web layer, web services layer, etc). The clients are on another machine and can be in another data center, so the front end and backend are never in the same app server.
The backend is layered as follows:
SLSB <-> Service Layer Objects <-> DAO
All objects are spring managed, except for the SLSB. The chain of events is as follows:
Initialization:
- Entity Manager injected into DAO
- DAO injected into Service Object
- Service Object injected into SL EJB
- SLSB's only provide a remote interface
All objects are Singleton and stateless
Request/Response:
method invoked on EJB, delegates to Service Object, uses DAO's, return DTO
The DAO's encapsulate all the query operations on JPA entities. No JPA entity bleeds past the service layer. The service layer demarcates the transaction.
What happens to the JPA entities once the request/response lifecycle is complete with this architecture? Should the service layer attempt to cache the entities, or is that hibernates job?
And any comments on this architecture is welcome.
thanks
- Billworth
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于 TRANSACTION 范围内的容器管理的持久性上下文，当关联的 JTA 事务提交或回滚并且持久性上下文中的所有实体都被分离时，持久性上下文就会结束。来自 JPA 规范：
如果应用程序不再保留引用，则分离的实体将被垃圾收集。
如果您想要跨各种持久性上下文缓存实体，即二级 (L2) 缓存，那么这就是 JPA 提供程序的工作。它了解各种持久性事件并可以与缓存进行适当的交互。当您的 JPA 提供商已经提供此功能时，在服务层实现类似的机制是没有意义的。对于 Hibernate，请参阅 19.2。二级缓存。
In the case of a container-managed persistence context that is TRANSACTION scoped, the persistence context ends when the associated JTA transaction commits or rolls back and all entities that were in the persistence context are detached. From the JPA specification:
Detached entities will then be garbage collected if the application doesn't hold a reference anymore.
If you want to cache entities across various persistence contexts, aka second level (L2) caching, that's a job for the JPA provider. It is aware of the various persistence events and can interact appropriately with a cache. There is no point at implementing a similar mechanism at the service layer level when your JPA provider already offers this feature. For Hibernate, see 19.2. The Second Level Cache.