利用实体EJB来避免性能缺陷：一种映射持久性数据的简便方法

时间：2014-05-04 10:33:16 来源：JSP天空网作者：未知

EJB （Entity Enterprise JavaBeans）是一种可以把持久性数据映射到Java组件上的简便
方法。CMP （Container-Managed persistence）提供了快速开发功能，这是因为EJB 容器
可自动处理持久性数据的加载和存储。然而，在具有许多优点的同时，如果Entity EJB没有
正确使用，也会导致性能的大幅下降。本专栏详细介绍了几个常见的编程缺陷，它们常常使
EJB的程序员犯错，并妨碍其实体（Entity）beans的性能。
Primary Key类
类似于数据库中的行，实体beans有一个主键（primary key）与它关联。这个主键可以是实
体bean的一个单一字段。在这种情况下，实体bean可以用字段的类作为主键。

还可能提供一种自定义的主键类。对于复合主键来说，必须定制一个主键类，来映射多个实
体bean的字段。

使用定制的主键类，开发人员必须实现hashCode和equals方法。因为EJB容器常在其内部数
据结构中使用主键类，所以这个类必须正确和有效的实现hashCode和equals方法（参见清
单1）。

清单 1:

一个低效但正确的主键类
public class MyPk
implements java.io.Serializable
{
public String str;
public int i;
public byte b;
public MyPk() {}
public int hashCode() { return -1; }
public boolean equals(Object o) {
if ((o != null) && (MyPk.class.equals(o.getClass()))) {
MyPk other = (MyPk) o;
return other.str.equals(str) && other.i == i && other.b == b;
} else {
return false;
}
}
}

实现hashCode方法
hashCode方法对于两个equal的对象，必须返回相同的值，而且应该相对均匀地分配哈希值
。下面显示的第一种实现方法正确而有效，但是根本没有分配哈希值。这个hashCode实现把
全部哈希表变换到一个列表中，而且必须线性检索。显然，这样违反了可检索性数据结构的
设计初衷。

private int hash = -1;
public int hashCode() {
if (hash == -1) {
hash = str.hashCode() ^ i ^ b;
}
return hash;
}

上面的hashCode实现计算了字符串的哈希值和原字段的异或（XOR）值。与其它的逻辑运算
符相比，诸如AND和OR，XOR应该是更可取的，因为它可以更好地分配哈希值。这种实现还可
以把哈希值缓存在一个成员变量中，以避免重复计算这个值。

实现Equals 方法
equals方法的功能是使用传入的参数比较当前对象，如果对象有相同的值，就返回true。默
认的java.lang.Object.equals用于比较引用（指针）值，如果它们相等就返回true。对于
大多数的主键类，需要重写这个方法，以便在主键类中比较这些值（参见清单 2）。

清单:2

一个有效的equals实现
public final class MyPk ...
public boolean equals(Object o) {
if (o == this) return true;
if (o instanceof MyPk) {
MyPk other = (MyPk) o;
return other.hashCode() == hashCode() &&
other.i == i && other.b == b &&
other.str.equals(str);
} else {
return false;
}
}

这是一种优化的equals实现，它的第一行用与此相反的方式比较传入的引用。第一，虽然这
看起来有点陌生，但这是EJB容器检查一个主键是否已经在它的数据结构中存在的常用方法
。

第二，我们已经用一个更有效的检查实例替代了getClass().equals。如果传入参数的类是
MyPk类或它的一个子类，操作符的实例将返回true。用final修饰MyPk类，这样创建的方法
可以安全地使用操作符的实例，因为这样就不存在子类了。

最后，比较哈希表和成员变量。Java中的表达式具有短路功能，这意味着如果第一个表达式
是false，第二个表达式将不再计算。这个equals方法很好的利用了这一点，先用最简易的
比较调整了and语句的顺序。在这个例子里，首先比较的是哈希值，这是因为我们的实现缓
存了这个值，而且发生两个对象具有相同的hashCode但却不相等的情况很少。接下来比较的
是原始字段；最后是调用花费资源最多的java.lang.String.equals。

加载和存储实体beans
WebLogic Server的EJB容器提供两种不同的实体bean类型：Read-Only 实体beans 和Read-
Write 实体beans。Read-Only 实体beans 支持高级群集缓存，关于这一点，将会在另一个
专栏中讨论。

实体beans是具有事务功能的对象。理解事务和持久性之间的关系是很重要的。当实体bean
的一个实例首次在事务中使用时，将会从数据库来刷新它的状态。对实体bean状态的任何修
改会立刻刷新到数据库中，而且会是在事务提交之前完成（在beforeCompletion回调中，详
细请参见 javax.transaction.Synchronization接口）。

让我们来看一个Employee 实体bean的例子，它具有所需的事务属性。可以假设我们在一个
单独的事务中创建了这个bean，而且当前它有一个指向Employee实例的引用。

Employee e = ...
String name = e.getName();
e.setSalary(e.getSalary() * 2);
e.setLevel(e.getLevel() + 1);

从上面的代码片断中得出的重要发现是调用者没有启动事务。因为bean是使用必需的事务属
性来部署的，每个方法都作为一个单独的事务运行，并加载、存储到数据库中。在这个例子
中，每一个getXXX方法导致了一次数据库读操作，而每个setXXX方法导致了一次数据库读操
作和一次数据库更新操作。这个简单的例子里有五个单独的事务，并有五次数据库读操作（
SELECTs）和两次更新操作。

Employee e = ...
tx.begin();
String name = e.getName();
e.setSalary(e.getSalary() * 2);
e.setLevel(e.getLevel() + 1);
tx.commit();

上面这个代码样例用单个事务包装了对Employee 实体bean的调用。在这个示例代码中使用
了一个UserTransaction的引用，用手工方式开始并提交事务。这些功能也可以用一个sess
ion bean来实现，它需要使用一个可用容器管理的事务，然后在容器事务中调用实体beans
。

当所有的业务方法都在一个单独的事务中执行时，只存在两种数据库访问。第一个getName
调用产生了一个从数据库加载的SELECT语句。随后的getXXX和setXXX 方法没有导致任何数
据库访问，因为它们在同一个事务中，而且数据已经被加载了。在事务提交时，将执行一个
UPDATE语句向数据库写入新的"salary"和新的"level"。

使用强制性事务属性

许多EJB的程序员用"Required"级别的事务属性来部署他们的beans。"Required"级别的事务
属性在多数情况下都能起作用，因为如果存在一个调用者的事务，它将继承这个事务；否则
它将启动它自己的事务。正如我们前面看见的，开发人员必须理解：事务属性是如何强烈影
响性能的。小组中的新程序员可能会在一个单独的事务中重用Employee 实体bean，并错误
地调用每个 getXXX方法。一种避免这种情况的方法是使用强制性（Mandatory）事务属性来
部署你的实体bean。和"Required"级别的事务属性不同，强制性（Mandatory）bean不会启
动它自己的事务。如果它和一个事务被同时调用，强制性bean将会参与到这个事务中。如果
强制性（Mandatory）bean没有和某个事务一起调用， EJB容器会立即向调用者抛出一个异
常。

用强制性（Mandatory）事务属性的来部署实体beans是一种容易的方法，它指出应该将这些
操作组织到一个调用事务中。

CMP的优势 - 加载Beans 的Finder

与业务方法一样，实体bean的finder方法的性能依赖于对事务的正确设置和使用。让我们来
考虑使用Employee Bean的另一个例子。

Collection employees =
home.findEmployeesWithSalariesGreaterThan(30000);
Iterator it = employees.iterator();
while (it.hasNext()) {
Employee e = (Employee) it.next();
double salary = e.getSalary();
}

这个简单的例子执行了一个finder（数据查询），用于返回其薪金大于传入参数（在本例中
，转入的参数为30,000）的雇员。然后从头到尾重复这个搜索过程，并从每个雇员中检索其
薪金。在finder返回了N个雇员的情况下，该例子将访问N+1次数据库。finder访问了数据库
，随后的每一个getSalary回调都访问了数据库。

到现在，你可能已经猜测出：我们试图在一个单独的事务中执行finder和getSalary方法。
现在，有多少次对数据库的访问呢？答案可能会令你惊奇。

如果Employee是一个CMP 实体bean，而且finder和随后的getSalary方法发生在同一个事务
中，那么只存在一次数据库访问。finder执行了一次选择查询，这次查询加载了对应的主键
和其它的Employee字段。这些预取出的beans被输入到EJB缓存中，而且getSalary方法直接
从内存缓存中调用读操作。这就是weblogic-ejb-jar.xml中的finders-load-bean选项。默
认状态下它是启用的。而且它允许finder从EJB缓存中预取出附加的数据。在这个常见的例
子中，对数据库访问从N+1次减少到了1次。

如果Employee类是BMP 实体bean将会怎样呢？令你吃惊的是，如果这样就还会有N+1次数据
库采样。如果Employee是一个BMP实体bean，该如何呢？这也许会令你惊奇，但它对数据库
的访问仍然是N＋1次。BMP 实体bean会在bean类中执行一个ejbFindEmployeesWithSalarie
sGreaterThan方法，以返回容器的一个主键集合，但它不会预取出到缓存中。然后每个get
Salary调用都会产生一个ejbLoad调用和另一个数据库访问。

Finder预取出beans是CMP在性能上的一大优势，一般来说，CMP（特别是EJB 2.0的CMP）实
体beans的性能要优于BMP 实体beans。

结束语
我希望这些技巧可以帮助您在实体beans之中获得更好的性能。我们还会在即将刊载的其它
专栏中讨论WebLogic Server 6.1 和EJB 2.0 中的实现技巧和新特性。

关于作者

Rob Woollen是BEA Systems公司WebLogic Server开发小组中的一位资深软件工程师。他拥
有普林斯顿大学的计算机科学学士学位。

来顶一下

返回首页

推荐资讯

后牧工业区厂房1500平	现实的童话公主艾米·
科比专为大场面而生	“最美清洁工”原是《

相关文章

无相关信息

栏目更新

栏目热门