本文已经讨论了很多内容，但是还未提及可应用于CMP bean的优化技术。比如，CMR缓存和字段组在某些环境下也很有用。选择最佳并发策略并充分利用长期缓存会给您的应用程序带来直接的性能提升。由于现在 各个WebLogic Server版本中可用的选项有诸多不同（对于其他J2EE服务器也是如此），所以有时候很难在某一具体情况下做出选择，尤其是如果开发人员没有调整这些 参数的经验的话。如果根本没有指定并发策略和缓存参数，WebLogic Server使用的默认设置从数据一致性方面考虑当然是不错的选择，但是从CMP bean的性能方面来看却不是最佳选择。没有放之四海皆准的东西，所以如果您不确定的话，应该分析您的用例，然后利用不同的并发设置进行测试，然后再作出 最佳选择。接着，我会讨论一些基本用例以及它们的推荐设置。
静态只读数据最可能的场景是，当数据库是静态（不随时间变化）、准静态（变化不频繁），或者从应用程序的角度来看可 当作静态或准静态，并且您的应用程序不修改这些数据时。比如，数据可能被外部进程频繁更新，但是如果您的应用程序只是每分钟/小时/天看到这些更新，那么 就没问题。这种情况下，使用带有适当read-timeout-seconds值的只读并发策略是合乎逻辑的。如果您的应用程序需要按照某种预定时间间隔 看到更新，或者有一个批处理过程来加载数据，而你需要马上看到新数据，那么就可以像前面描述的那样，显式地禁用缓存。比如，您可以在应用程序的正面暴露一 个“CMP缓存失效服务”，然后在批处理的最后或者从调度程序中调用。这种情况下缓存大小很容易计算，因为需要该缓存的所有事务共享同一个CMP实例，所 以不需要考虑多版本及其对缓存大小的影响。要根据表大小、单个对象大小以及可用内存选择合理的缓存大小。
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。
