数据库式的并发策略不同于数据库的并发控制。实体bean在容器中并未被锁定，允许多个交易对相同的实体bean并发操作，因此能够提高性能。当然，这样对隔离的级别也许要求较高，以便确保数据的一致性。
　　积极式并发策略与数据库的并发控制也不同。不同之处在于对数据一致性的检查发生在对已设定的更新操作进行存储时而非在装载时将整行锁定。如果应用内对同一个bean访问的冲突不是很激烈的情况下，本策略比数据库式的策略要快一些，虽然两个提供了相同的数据一致性保护级别。但是在有冲突发生的时候，本策略要求调用者要重新发起调用。本特征也只对EJB 2.0 适用。

　　只读式策略只能用于只读bean。Bean只在应用第一次访问时或者超出参数read-timeout-seconds所指定的值时才被装载。Bean从来不需要被存储。当基本数据改变时，也会通过read-mostly格式通知bean,从而引起重新装载.

　　紧密关联缓存: 如果两个实体bean, bean A 和bean B 在CMR(容器关系管理)内关联，两个在同一个交易中被访问，且由同样的数据库调用装载，我们称为紧密关联缓存。这是WebLogic Server 7.0的新特征，同样只适用于EJB2.0。

　　除了上面列出的通过优化容器内对数据库的访问从而达到性能增加的特征外，另有一些在容器之外，针对会话bean和实体bean的参数能够帮助提升性能。

　　缓冲池和高速缓存是EJB容器为提高会话bean和实体bean性能所提供的主要特征。然而，这些方法并非对所有类型的bean适用。它们的消极面是对内存要求较高，虽然这不是主要的问题。缓冲池适用于无状态会话bean(SLSB)，消息驱动bean(MDB)以及实体bean。一旦为SLSB和MDB设定了缓冲池的大小，这些bean的许多实例就会被创建并被放到缓冲池中，setSessionContext()/setMessageDriveContext()方法会被调用。为这些bean设置的缓冲池的大小不必超过所配置的执行线程数(事实上，要求比此数要小)。如果方法setSessionContext()要做任何开销昂贵的操作的话，此时JNDI查询已经完成，使用缓冲池中的实例方法调用将会加快速度。对实体bean来说，在完成setEntityContext()方法调用之后，缓冲池与bean的匿名实例相连(没有主键)。这些实例可以被查询操作所使用，查询方法从缓冲池中取出一个实例，为其指定一个主键，然后从数据库中装载相应的bean。

　　高速缓存适用于有状态会话bean(SFSB)和实体bean。实体bean已经在前面讨论过。对于SFSB，缓存能够避免向硬盘串行化的操作。串行化到硬盘的操作非常昂贵，绝对应该避免。用于SFSB的缓存大小可以比连接到服务器的并发客户端数略微大些，这是由于仅当缓存被占用了85%以后，容器才会设法将bean滞留在数据库中待命。如果缓存大于实际所需，则容器不会通过缓存花费时间将bean待命。

　　EJB容器提供了两种方法进行bean-to-bean 和 Web-tier-to-bean的调用操作:传值调用和传送地址调用。如果bean处在同一个应用之中，则缺省情况下，用的是传送地址的方法，这比传值要快一些。传送地址的方法一般不应被禁止，除非有充足的理由要强制这样做。强制使用传送地址的另一种做法是使用本地接口。在WebLogic Server 7.0中引入了另一个特征是对有状态服务使用激活(activation)。虽然这种做法在某种程度上影响了性能，但由于对内存要求较低，因此极大地改进了扩展性。如果扩展性不值得关注，可以将参数noObjectAction传送给ejbc从而关闭激活(activation)。

　　JDBC

　　对数据库的访问来说，调试JDBC与调试EJB容器同样重要。比方说设置连接池的大小?D?D连接池应大到足以容纳所有线程对连接的要求。如果所有对数据库的访问能够在缺省的执行队列中得以实现，则连接数应为执行队列中的线程数，比读取socket的线程(缺省执行队列中用来读取进入请求的线程)数要少。为了避免在运行期间对连接进行创建和删除，可在初始时即将连接池设置为其最大容量。如果可能的话，应确保参数TestConnectionsOnReserve被设置为假(false，这是缺省设置)。如果此参数设置为真(true)，则在连接被分配给调用者之前，都要经过测试，这会额外要求与数据库的反复连接。

　　另一个重要的参数是PreparedStatementCacheSize。每个连接都为宏语句设一个静态的缓存，大小由JDBC连接池配置时指定。缓存是静态的，时刻牢记这一点非常重要。这意味着如果缓存的大小是n的话，则只有放在缓存中的前n条语句得到执行。确保昂贵的SQL语句享受到缓存的方法是用一个启动类将这些语句存放到缓存中。尽管缓存技术从很大程度上改进了性能，但也不能盲目使用它。如果数据库的格式有了变化，那么在不重新启动服务器的情况下，无法使缓存中的语句失效或者是用新的进行替换。当然，缓存中的语句会使数据库中的光标得以保留。

　　对于WebLogic Server 7.0来说，由于jDriver性能的改进已使其速度远远快于Oracle的?C驱动程序，尤其对于要完成大量SELECT操作的应用来说就更是如此。这可以从HP提交的利用WebLogic Server 7.0 Beta版的两份Ecperf结果得到证明(http://ecperf.theserverside.com/ecperf/index.jsp?page=results/top_ten_price_performance)。

　　JMS

　　JMS子系统提供了很多的调试参数。JMS消息是由称为JMSDispatcher的独立执行队列处理的。因此，JMS子系统既不会由于运行在缺省或者其它执行队列中的应用因争夺资源而导致“营养匮乏”，反过来也不会抢夺其它应用的资源。对JMS来说，大多数的调试参数都是在服务的质量上进行折衷处理。如，利用文件式持续性目的地(file-persistent destnation)禁止同步写操作(通过设置特性: -Dweblogic.JMSFileStore.SynchronousWritesEnabled =false)以后会引起性能急剧提高，但同时也会冒着丢失消息或者重复接收消息的风险。类似地，利用多点传送发送消息会提升性能，同时也会有消息半途丢失的危险。