WebLogic Server中CMP实体bean的性能调优[10]

　　WebLogic Server中CMP实体bean的性能调优[10]  软件测试

　　Read-mostly数据

　　也许最常见的情形是，数据被读取的频率大于其被更改的频率。这正是缓存可成功应用的场合。我建议使用启用了事务间缓存的乐观锁定。如果数据库模式可更改，我通常指定一个verify-columns的整型值，如果数据库模式不可更改，就指定一个Modified值。如果您决定使用一个版本列，那么要保证外部进程(如果有的话)在数据发生变更时遵守版本列更新的协定;否则，面临更新丢失的风险。

　　从选择适当的缓存大小方面来看，应该考虑多版本化，以及从finder方法返回的最大bean数目。一个不错的上限估计方法是将应用程序需要同时处理的最大事务数乘以单个事务可以处理的最大bean数。我通常建议使用更加灵活的应用程序级缓存，因为通常不太可能所有的CMP都同时被使用。应用程序缓存对于所有CMP来说是全局的，会自适应不同bean的活动。如果您定义了一个过大的应用程序级缓存，可能会损害性能，因为所有事务都会串行访问这个唯一的缓存。对于大小适当的缓存来说极少出现这个问题，但是同样，在您不确定缓存大小如何影响性能时应该进行性能测试。顺便说一下，良好的设计实践是，避免创建返回任意多实体bean的finder方法(比如，大型表上的findAll())，因为这使得估计出适当的缓存大小变得几乎不可能。

　　带有事务间缓存的乐观并发最适合有缓存碰撞“保护”的用例。比如，在一个项目用例中，应用程序需要处理传入消息(来自JMS)。每个消息记录需要在数据库表中创建，然后必须发送另一个消息作为响应;对于第二个消息来说，应用程序希望在一分钟内收到响应，并且在收到该响应时，同一条数据库记录得到更新。这时在该场景中应用缓存会带来巨大和直接的性能收益。我们“保证”每个被缓存的项目至少有一个碰撞，如果缓存对于保存CMP实例来说过大的话。

　　另一个极端是目标表太大，以至于不可能对同一数据作出重复请求。从实践角度来看，这是不可行的，并且缓存这样的数据不能提高性能。

　　在上述的read-mostly模式中，乐观并发模式应该是更好的选择。read-mostly模式不能用于集群中，不能防止出现更新丢失，并且一般来说不便于使用。本文讲述它是为了提供关于所有可用策略的整体情况，但是我不鼓励在现代应用程序中使用它。

　　Read-mostly数据

　　如果您的应用程序主要是插入或更新记录，那么缓存数据意义不大，因为几乎不会再次访问它们。在只进行插入操作(OLTP)的极端情况下，缓存反而会减慢处理速度。非重复性更新(对表中远超过缓存大小的随机行的更新)也很少从CMP缓存中受益。此外，随着更新数目相对于读取次数的增加，乐观并发策略的表现越来越差，因为会出现大量的乐观并发异常。实际上，如果您的应用程序只在数据库中更新和插入记录，就根本没有必要使用实体bean。

　　结束语

　　从本文的长度就可以看出，调整CMP 2.0 EJB有很多内容。我首先讲述了可用的各种并发策略。然后讨论了一些重要的性能策略：read-mostly模式，事务间缓存，以及选择最佳缓存大小。最后，我提供了关于在何种情况下使用何种策略的指南。我希望这些分析能帮助你更好地理解EJB。

原文转自：http://www.ltesting.net