EJB Extended 与Seam-managed Persistence Context

本文将简单谈谈我对 EJB 3.0 的两种 Persistence Context 和 Seam-managed Persistence Context 的不同点的理解、所要解决的问题和我自己所疑惑的问题。

EJB 3.0 (JPA) 的 Persistence Context

大家在使用 EJB 3.0 的时候会注意到 EJB 3.0 中的容器管理 Persistence Context 有两种类型,一种是 Transaction,另一种是 Extended。这是一个较 Hibernate 的 Session 所没有的概念,Session 没有两种不同的类型,而且最重要的是 Session 不是容器管理的,这里的容器指的是 App server 容器。这里暂时不谈论 Persistence Context 与 Session 之间的异同,主要谈谈两种 Persistence Context 之间的不同。学过 ORM 的同学都知道,当 Persistence Context 是打开状态的时候,Model 就处于被管理的状态中;当 Persistence Context 关闭之后,Model 就处于了 Detached 状态。

上面这些特性对于 Transaction 或 Extended 的 Persistence Context 都是一样的,不同的地方在于 Persistence Context 何时被打开关闭。由于绝大多数情况下 Persistence Context 是被容器管理的(如果你不嫌累也可以自己控制 Persistence Context),所以在 EJB 3.0 应用中看不到打开或关闭 Persistence Context 的代码(Spring + Hibernate 的应用也同样如此,Hibernate Session 的管理工作可以交给 Spring 来做)。

其实,Transaction 和 Extended Persistence Context 的不同之处也就在于容器何时打开或关闭 Persistence Context。Transaction 类型的 Persistence Context 的打开和关闭是和事务的打开和关闭是同步的。也就是说在一个事务开始之后,Persistence Context 才会开始;在事务关闭的时候,相应的 Persistence Context 也会被关闭。

Extended 类型的 Persistence Context 的打开和关闭是和 Stateful Session Bean 的生命周期同步的,是跨越事务的。也就是说,从 SFSB 的初始化开始,直到销毁,Persistence Context 都是存在的。你可以在事务之外执行写操作,但是这是并不会执行真正的数据库操作,写操作只是放入了队列,直到下一个事务,写操作才会真正地被执行。两者的不同简单说来就是 Extended Persistence Context 存在的时间更长。那为什么要有两种不同的 Persistence Context 呢?

当一个 Web 请求到来时,服务器会打开一个线程,这个线程可能会调用一个事务方法,这是一个事务便开始了,当这个请求结束时,线程关闭,事务也随之结束。由于 Transaction 类型的 Persistence Context 的生存周期是在事务范围之内的,所以一个 Web 请求的结束也意味着相应的 Persistence Context 的关闭。由于多数 Web 应用在一次 Web 请求内即可完成一个独立的操作,所以大部分情况下 Transaction 的 Persistence Context 是适用的。但是对于一些复杂的应用,一次操作需要跨越多次请求。这种情况下,如果依旧使用 Transcation 的 Persistence Context,由于每次请求结束后,相应的 Persistence Context 都被关闭,相应的 Model 也就变为 Detached 状态。如果接下来的请求仍然需要这些已经变为 Detached 状态的 Model 就需要重新 load,使用 merge() 方法来持久化。稍有不适就会产生 LazyInitializationException 和 NonUniqueObjectException。同时,这也提高了操作的复杂程度。

如果使用 Extended Persistence Context 就能解决这些问题。由于 Extended Persistence Context 的生命周期是与 SFSB 的生命周期同步的,所以只要多次请求调用的都是同一个 SFSB 中的方法,有多少次的请求,Persistence Context 总是同一个,其中的 Model 也始终是被管理的。很好地解决了 Persistence Context 在线程之间传递的问题,也不会有 LazyInitializationException 和 NonUniqueObjectException 问题的发生。

时间: 2024-10-06 14:09:33

EJB Extended 与Seam-managed Persistence Context的相关文章

Java Persistence with Hibernate中文版Hibernate实战第2版出版

Java Persistence with Hibernate中文版Hibernate实战第2版出版 图灵出版社官方Hibernate实战(第2版)链接为: http://www.turingbook.com/Books/ShowBook.aspx?BookID=260 书 名: Hibernate实战(第2版) 评论星级: **** 书 号: 978-7-115-17448-2 原 书 名: Java Persistence with Hibernate 原出版社: Manning Publi

将遗留Hibernate应用程序迁移到OpenJPA和EJB 3.0(一)

简介:通过使用 EJB 2.1 以及 OpenJPA 和 EJB 3.0 中的等效功能比较 Hibernate 应用程序中的特 性和功能,学习如何将 Hibernate 应用程序源代码.对象关系映射和配置参数迁移到 OpenJPA. 引言 Hibernate 是开放源代码持久性和查询框架,提供传统 Java 对象 (POJO) 到关 系数据库表的与对象相关的映射,以及数据查询和检索功能.Apache OpenJPA 项目将按照 EJB 3.0 Java Persistence API 规范的定义

前进:从EJB 2.1到EJB 3.0

在开始讨论怎样从EJB 2.1迁移到EJB 3.0之前,有必要先了解一下迁移之后将会得到什么:主要来说,EJB 3.0减少了在创建EJB时所需的类.接口.部署描述符的数量.EJB 3.0通过用纯旧式Java对象(POJO)取代抽象bean类,用纯旧式Java接口(POJI)取代组件与主接口(Component & Home),简化了EJB的开发过程,在此,后者是可选项--你不必全部包含进它们. 部署描述符--ejb-jar.xml--由其指定了EJB名.bean对象名.接口.查找者方法.容器管理

JavaBeans:游离实体

当transaction scope persistence context或extended persistence context结束之后,实体的实例就会不受托管而处于游离状态.游离实体的一个值得注意的特征是,它可以被序列化并通过网络发送给远程客户端.客户端可以修改这些经过序列化的对象实例,并将它们发送回服务器,服务器再将客户端的修改重新合并到数据库中. 这与EJB 2.1的实体模型有很大的不同.在EJB 2.1中,实体是始终受容器管理的,使用entity bean的应用程序总要带一个指向e

对ORM的支持 之 8.4 集成JPA ——跟我学spring3

8.4  集成JPA        JPA全称为Java持久性API(Java Persistence API),JPA是Java EE 5标准之一,是一个ORM规范,由厂商来实现该规范,目前有Hibernate.OpenJPA.TopLink.EclipseJPA等实现.   8.4.1  如何集成        Spring目前提供集成Hibernate.OpenJPA.TopLink.EclipseJPA四个JPA标准实现.        Spring通过使用如下Bean进行集成JPA(E

J2EE deployment files(ejb-jar2.0.xml)

j2ee|xml <ejb-jar> The ejb-jar element is the root element of the EJB deployment descriptor. It contains an optional description of the ejb-jar file, optional display name, optional small icon file name, optional large icon file name, mandatory stru

J2EE 探险者:持久数据管理,第 1 部分

j2ee|数据 J2EE 平台为管理企业数据持久性提供了一组丰富的选项,但如何选择适合于您体系结构的选项呢?Kyle Gabhart 介绍了 J2EE 最佳的数据持久性技术 - 实体 bean.JDBC 和 JDO - 并在几个不同环境中比较它们.数据持久性是企业开发中最棘手的一个方面.一个企业数据持久性解决方案必须提供迅速的客户机事务,随着时间的过去确保数据完整性,以及在如系统崩溃和网络故障之类的日常灾祸发生时使数据继续存在.在 J2EE 探险者系列接下来的两个部分中,我们将着重讨论 J2EE

J2EE 探险者:持久数据管理,第 2 部分

j2ee|数据 上月的"探险者"专栏介绍了用于数据持久性的 J2EE 技术:实体 bean.JDBC 和 Java 数据对象(Java Data Object,JDO).本月,企业 Java 专家 Kyle Gabhart 不再专门讨论比较成熟的 JDBC 技术和 EJB 技术,而是主要介绍 JDO.尽管这种技术与其它技术相比还不成熟,但您会发现 JDO 有一些独一无二的优点. 应用程序组件应实现针对企业服务的请求.要实现这些请求,应用程序组件常常必须更改底层数据存储的状态.这些更改绝

J2EE 中使用EntityBean和JDO各有什么优点缺点

j2ee 实体 bean: 提供健壮的数据持久性.bean 容器处理大部分的数据完整性.资源管理和并发性功能,从而使开发人员关注业务逻辑和数据处理,而不是这些低级细节.使用 bean 管理的持久性(Bean Managed Persistence,BMP)实体 bean 时,开发人员编写持久性代码而容器确定何时执行该代码.使用容器管理的持久性(Container Managed Persistence, CMP)实体 bean 时,容器生成持久性代码并管理持久性逻辑. JDO: 只是提供面向对象