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状态的任何修改会立刻刷新到数据库中，而且会是在事务提交之前完成。

让我们来看一个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的引用，用手工方式开始并提交事务。这些功能也可以用一个session 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类中执行一个ejbfindemployeeswithsalariesgreaterthan方法，以返回容器的一个主键集合，但它不会预取出到缓存中。然后每个getsalary调用都会产生一个ejbload调用和另一个数据库访问。

finder预取出beans是cmp在性能上的一大优势，一般来说，cmp（特别是ejb 2.0的cmp） 实体beans的性能要优于bmp 实体beans。

注：作者 rob woollen是bea systems公司weblogic server开发小组中的一位资深软件工程师。他拥有普林斯顿大学的计算机科学学士