Weblogic中使用持久缓存技术优化CMP性能

核心提示：当前，在持久性方面CMP（容器管理持久性）虽然不是很流行的选择，Weblogic中使用持久缓存技术优化CMP性能，但它仍然是企业环境中惟一立即可用的持久性框架，尽管不如hibernate或SQL Maps那么有吸引力，而8.1以上版本似乎解决了这个问题，我们已经将它应用于生产应用程序中，但领先的应用服务器（如BEA W

当前，在持久性方面CMP（容器管理持久性）虽然不是很流行的选择，但它仍然是企业环境中惟一立即可用的持久性框架。

尽管不如hibernate或SQL Maps那么有吸引力，但领先的应用服务器（如BEA Weblogic）中的CMP2.X实现也提供了非常好的ORM（对象角色建模）问题解决方案。此外，有许多开发人员熟悉EJB，从xdoclet到Eclipse wtp/jst的各种工具也为之提供了完善的支持。

先看看在Weblogic中通过启用更好的而不是使用默认的缓存策略，能否提高CMP的性能。

大家都知道EJB容器保留了实体Bean的缓存或池，它们通常可在部署描述符中配置。这并不意味着容器从数据库中加载了特定的bean实例之后就不再访问数据库，而是将bean实例保存在池中，令人惊讶的是，许多开发人员没有意识到这一点。恰恰相反，默认情况下，在每个事务开始的时候，容器调用ejbLoad()同步数据库中实例的状态。基本上在每个使用CMP bean的操作中，即使bean在数秒前的前一个事务中已经加载了，容器也会执行SQL选择语句刷新它。只有在事务中使用CMP实例进行操作时容器才会缓存它们。这就是EJB2.0规范（10.5.9）中描述的所谓“Commit Options A/B/C”。

很明显对于每次事务都从数据库重新加载状态会影响性能。很容易理解为什么这被设为默认行为——如果多个进程共享数据库，并且每个进程都能改变数据库中持久对象的状态，而该状态缓存在EJB池中，这种情况下这是最安全的方法。这种情况下可能会丢失更新信息——其他进程的更新信息记录在数据库中，而容器使用缓存中可能已经失效的数据将其重写。但是在事务开始时首先更新数据并不能保证不丢失更新信息，而只能减少丢失的可能性。在数据库领域中这是一个众所周知的问题，有两个方法可以解决该问题。第一种方法就是所谓的“悲观并发锁定”，即在事务的持续时间内当在数据库中记录时锁定其他的更新进程（使用“select for update”语句）。但是由于开销巨大和性能降低，该方法几乎不使用。第二种方法称为“乐观并发锁定”，在该方法中，数据库中没有实际的锁，但是执行更新的进程会使用某种机制检测在其读取和更新之间记录是否被其他进程更新过。首选的实现方法是使用数据库表格中的version列（在SQL中更新该列的increment属性值，包括where子句中的先前的值，然后检测，如果没有行被更新的话）。

通过weblogic-cmp-rdbms-jar.xml部署描述符中的verify-columns元素，Weblogic已经在CMP bean中内置乐观并发支持。对数据库中的所有（可更新的）表格都使用version列，并通过在weblogic-ejb-jar.xml中的并发策略元素中启用乐观并发策略，配置使用CMP，这是一个良好的实践。

乐观并发本身并不能带来任何性能改进，但它是启用cache-between-transactions功能的必要步骤，该功能没有启用乐观并发时不可用（原因如上所述）。如果EJB缓存中的bean实例已经可用，将cache-between-transactions设置为'true'会导致容器跳过ejbLoad()调用。对于某些类型的应用程序，在短时间内相同的对象会被不同的事务多次访问，则上述方法将使性能大大提升（在我们的测试中，应用程序性能提升了30％）。

当然，当容器检测到并发错误时，应用程序必须能马上处理OptimisticConcurrencyException。当抛出OptimisticConcurrencyException（运行时异常的子类型）时，容器从缓存中删除EJB实例。在集群中，当更新使用乐观并发的bean时，会广播通知给其他集群成员以防止乐观冲突。注意，如果delay-updates -until-end-of-tx设置为'true'（默认值），代码将在事务提交后才能看到乐观异常。

一些说明。虽然已经出现了很长一段时间，但Weblogic 7中的cache-between-transactions功能常常不起作用，而8.1以上版本似乎解决了这个问题。我们已经将它应用于生产应用程序中，并对其效果非常满意。