具有扩展持久性上下文的有状态EJB可以处理用户会话

| 我正在使用CDI会话作用域bean来保存与用户相关的信息(他的用户实体bean,凭证等)。每当用户更改其信息(例如电子邮件,密码等)时,我都有一个保存方法。 但是,我可以使用带有扩展持久性上下文的有状态会话Bean来实现。如果这样做,他的用户实体将在他的会话期间得到管理,对他的电子邮件等的更改将被同步,而无需重新创建持久性上下文等。 这是一个好主意吗?我应该开放这么长时间的扩展持久性上下文吗?这也将更改锁定给外部Bean的用户,对吗?如果我有一个管理员试图对此用户进行更改怎么办(可能会发生)。     
已邀请:
        您需要注意一些副作用。 第一件事是,用于保存该用户实体的扩展持久性上下文不应用于其他用途,因为它会自动缓存所有被触摸的内容(L1缓存)。 如果需要在处理其他持久性上下文的其他操作中使用此连续连接的用户实体,则需要获取一个新实例,而不是在会话范围内使用该实例。 锁定不会自动发生。通常,不同的持久性上下文也可以修改同一实体。通常,最后一个执行任何写操作的操作都会“赢”。如果要防止这种情况,可以利用JPA中的常规锁定操作。对于这种情况,乐观锁可能是最合适的。 我很好奇这在实践中效果如何。这肯定是一个新颖的想法。通过阅读许多博客文章,文章,书籍以及与许多开发人员的讨论,我感到扩展的持久性上下文是鲜为人知的事情,并且没有为此创造太多的最佳实践。 现在可以通过CDI对有状态会话Bean进行范围划分(并因此在销毁HTTP会话时自动销毁),从而使整个概念变得更加可行。但是CDI还是一个相对较新的事物,许多人仍然必须发现如何最好地使用它。     
        我在各种Java EE 6项目中使用扩展的持久性上下文,这是这种情况: \“ facade \”(sfsb),注入服务 “服务”注入EM \“ dbproducer \”将EM生成到外观的对话范围内 门面默认情况下禁用所有交易(例如,
loadEntity()
没有交易) 某些外观方法显式启用了事务处理(例如
saveEntity()
具有翻译) 发生的事情是: 在对话的整个持续时间内,实体将被加载并保持受管理状态(由持久性上下文完全缓存,在没有事务的情况下,持久性上下文将不会刷新)。 如果(并且仅出于示例目的)保存了一个实体,则将显式打开一个事务,并且如果事务成功,则持久化上下文将刷新到db中。 如果确实进行了其他任何编辑(例如,由管理员执行),则将抛出
OptimisticLockingException
并由应用程序处理 这就像一个假面,并且感觉也很优雅:-) 一句话警告-因为EM不可序列化-*如果*您在集群中工作,则将不得不使用粘性会话策略,因为这些EJB无法从一台服务器移动到另一台服务器其他。 您可能还想考虑使EM加入现有事务的某种方法(如果每个请求有多个服务调用,这很容易发生)。如果使用非Seam 3堆栈,则可以选择代理EM;如果使用Seam 3,则使用
@Unwraps
(焊锡)代替S4ѭ,并检查是否有要加入的交易。     

要回复问题请先登录注册