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开发小组中的一位资深软件工程师。他拥
有普林斯顿大学的计算机科学学士学位。
