将 WebLogic 服务器和应用程序配置迁移到 WebSphere Application Server.docx

2007 年 10 月 09 日本文描述如何将 WebLogic 应用程序和服务器配置迁移到 IBM WebSphere Application Server，其中介绍了一些 WebLogic 专有扩展。您必须对这些专有扩展进行恰当的映射才能使您的应用程序在 WebSphere Application Server 上运行。其中给出了常见问题的解决方案，所以能最大限度地减少您实施迁移的阻力。引言本文旨在帮助您将 Java 2 Platform, Enterprise Edition (J2EE) 应用程序从 BEA WebLogic Server 迁移到 IBM WebSphere Application Server 平台。在其他一些 developerWorks 文章中讨论了 WebLogic 迁移规划，包括开发环境、产品运行库、应用程序代码等的迁移。本文着重介绍 J2EE 应用程序中存在的两类配置，以对这些参考资料及其他资料进行补充。这两类配置分别是： 服 务器配置指的是不在应用程序文件中，但包含在开放源代码环境的域配置中的设置。要迁移服务器配置，需要将特定于 WebLogic 的资源（例如 JMS 连接工厂、JMS 队列、JMS 主题、JDBC 数据源、JavaMail 会话等）映射到 WebSphere Application Server 上的等价体。 应 用程序配置指的是企业存档 (EAR) 文件的应用程序目录结构中自包含的设置。要迁移应用程序配置，需要将特定于 WebLogic 的部署描述符映射到 WebSphere Application Server 上的等价体。本文讨论的内容直接适用于将 J2EE 1.3（或更高版本）的应用程序从 WebLogic Server 7.0 和 8.1 迁移到 WebSphere Application Server V6.x。这里的大多数信息也适用于从早期版本的 WebLogic Server 迁移应用程序。迁移服务器配置迁移服务器配置实质上指的是将 WebLogic Server 上的位于应用程序文件外（但包含在域配置中）的设置移到 WebSphere Application Server 上。这些设置可以是 JMS 连接工厂和目的地、JDBC 数据源、J2EE 安全设置、邮件会话等等。要迁移该配置，您必须知道需要迁移什么设置。然而，您很可能没有任何关于这些设置的文档或脚本（创建服务器配置可能要用到 它们）可供参考。如果是这样，您需要登录到每个域中的 WebLogic 管理控制台来查找该设置，以确定需要在 WebSphere Application Server 环境中创建哪些设置。但如果您无法（或没有权限）访问 WebLogic 管理控制台呢？对于任何一种方式，收集 WebLogic 服务器配置信息的最有效方法就是检查 WebLogic 域配置文件 config.xml 和 WebLogic 启动脚本。WebLogic 管理员通常会向您提供这些文件的副本，因为查看这些副本文件不会影响任何正在运行的系统。 WebLogic config.xml 文件是 WebLogic 管理控制台存储所有资源定义的地方。没有恰当地映射这些资源可能导致应用程序失败。 管理员通常创建一个自定义的启动脚本，然后向其添加系统属性、JVM 参数和类。没有将这些设置成功地迁移到新的环境中可能会对应用程序的性能和可伸缩性造成负面影响。最好对该启动脚本加以检查，不管是查看 config.xml 文件还是查看管理控制台。在收集到此信息后，务必让开发人员和管理员检查您收集的信息。这是为了： 确认您收集的信息所包含的设置最新且最准确。 找出任何可以删除的死代码。此外，还能保证您查看的是正确的 WebLogic 服务器配置；在开发过程中，J2EE 应用程序可能会安装在许多不同的运行时环境（开发、测试、QA 等）中，每个环境都会有略微不同的配置设置。因此，要确保所使用的 WebLogic 服务器配置是您打算使用的那个。同样地，当您在每个开发阶段安装应用程序时，请确保在每个相应的环境中映射了合适的服务器配置。对于手头需要迁移的特定运行时配置设置，接下来的步骤是将它们提取出来并将信息插到 WebSphere Application Server 管理控制台中。虽然这是一个手动过程，但是一旦知道需要创建哪些设置，创建起来并不困难。使用 WebSphere Application Server 管理控制台来设置这些属性可以使您从修改 XML 文件或编写脚本中脱身出来。如果您愿意，也有指导操作可帮助您执行常见任务，例如创建数据源、启用 J2EE 应用程序安全性。一旦完成后，您可以编 写脚本来自动创建服务器配置，特别是在生产环境中。图 1 阐释了从 WebLogic 到 WebSphere Application Server 的服务器迁移。这里显示的设置并非只是服务器配置设置，而是涵盖您在此类迁移的过程中所看到的大多数设置。您看到的其他设置可能是与安全性和邮件会话相关 的，但是从整体上讲，如果您可以处理图中所示的资源，您就离成功迁移服务器不远了。图 1. 服务器配置迁移迁移应用程序配置迁移应用程序配置实质上指将包含在特定于 WebLogic 的部署描述符中的设置移到 WebSphere Application Server 中。这些设置包括从 EJB 组件到全局 JNDI 命令空间的映射、各种性能相关的设置（例如池大小）、事务的隔离级别、EJB 查询语言的扩展，等等。部署描述符描述了 J2EE 应用程序所需的执行环境，它有两种常规变体： 本文并不讨论 Web 服务的部署描述符，它们的映射将在后续文章中介绍。 行业标准部署描述符（图 2）是可移植的，通常不需要做任何更改，但 WebLogic 和 WebSphere Application Server 之间的一些区别值得一提。例如，IBM 的标准部署描述符使用 ID 来对标准描述符中的信息与特定于供应商的描述符中的信息进行关联，而 WebLogic 则使用 ejb-name 进行关联。因此，当您迁移 WebLogic 部署描述符并创建特定于 IBM 的描述符时，需要向其添加适当的 ID。您可以让您的组装工具（例如 IBM Rational Application Developer）来为您创建这些 ID；如果您试图自己创建这些 ID，出错时解决这些错误会很棘手。图 2. 行业标准部署描述符 特定于供应商的部署描述符（图 3）必须迁移。图 3 显示了特定于 WebLogic 的部署描述符和相应的特定于 WebSphere 的部署描述符。图 3. 特定于供应商的部署描述符IBM 提供了大量工具来帮助您将 WebLogic 部署描述符迁移到 WebSphere Application Server，包括：o Xdoclet 标记o WebSphere Rapid Deployment 标记o Application Server Toolkit（部署描述符编辑器）o IBM J2EE Competitive Migrator Plug-in for Rational Application Developer V6。请查看 Migrating Applications from WebLogic, JBoss and Tomcat to WebSphere V6 来了解这些工具的用途、使用方法和使用时机、如何获得帮助等。了解这些工具并在恰当时候使用它们是很重要的。虽然这些工具会映射特定于供应商的部署描述符 中的一些扩展，但不会映射所有扩展，所以检查部署描述符并了解如何映射在其中发现的扩展是很重要的。了解这些内容后，使用组装工具（如 Application Server Toolkit）是十分有效的。回页首映射 config.xml 元素本部分描述如何将这些服务器配置元素从 WebLogic 映射到 WebSphere Application Server：a. JMSConnectionFactory b. JMSFileStore c. JMSServer d. ForeignJMSServer e. JDBCConnectionPool 和 JDBCDataSource 有关每个元素的详细信息，请参阅 WebLogic Server Configuration Reference。a. JMSConnectionFactory JMSConnectionFactory 元素创建连接工厂对象并将其绑定到 JNDI 命名空间。对于此应用程序，config.xml 文件中配置了三个连接工厂，每个连接工厂都启用了 XA：为了将此配置映射到 WebSphere Application Server，您通常会在 WebSphere 缺省消息传递提供程序中创建 JMS 连接工厂，如上所示。其他一些预防措施包括：o 在 WebSphere Application Server 中配置这些 JMS 连接工厂时使用正确的 JNDIName。如果 JNDI 名称不正确，则应用程序将无法定位连接工厂。o 确认消息驱动 bean (MDB) 是否为事务型的，因为对于指定事务属性为 “NotSupport” 的非事务型 MDB，禁用 XA 会使性能有所提高。非事务型 MDB 不能参与 XA 事务，不需要已启用 XA 的连接工厂。另一方面，如果 MDB 指定事务属性为 “Required”，则应该为其 connection-factory-jndi-name 启用 XA。o 当您在 WebSphere Application Server 中创建连接工厂时，XA 缺省为启用。b. JMSFileStore JMSFileStore 元素定义了一个基于磁盘的 JMS 文件存储，它在文件系统目录中存储持久消息（用于队列）和永久订阅者（用于主题）。以下代码片段显示了单个 JMS 文件存储的定义：要将此配置映射到 WebSphere Application Server，首先需要知道 WebSphere Application Server V6.0 缺省消息传递机制并不支持 JMS 文件存储。该文件存储是 Version 6.1 中的一个增强功能，如果您使用 Version 6.0，则需要为消息传递引擎定义一个 JDBC 数据源。c. JMSServer JMSServer 元素定义了一个 JMS 服务器，它管理到其 JMS 目的地的连接和消息（使用 JMSQueue 或 JMSTopic 元素）。以下取自 config.xml 文件的代码片段显示了三个 JMS 服务器，每个服务器都包含两个 JMS 目的地，这里使用 JMS 队列： 在此 WebLogic 配置中，只有其中一个 JMS 服务器 (JMSServerMailing) 使用文件存储。其他两个没有指定任何 JMS 存储，所以在这些 JMS 服务器中的队列不支持持久消息。除非应用程序显式设置目的地的传递模式（PERSISTENT 或 NON_PERSISTENT），否则 WebLogic config.xml 文件将指定消息是否是持久性的。因此，具有非空文件存储的 JMS 服务器到目的地的传递将使用持久传递模式，而没有文件存储的 JMS 服务器将使用非持久传递模式。要将此配置映射到 WebSphere Application Server，请对 JMSServerMailing JMS 服务器中定义的两个目的地使用持久消息传递机制，对其他所有目的地使用非持久传递模式。再次说明，在 WebSphere Application Server 中配置这些 JMS 队列时务必使用正确的 JNDIName。如果 JNDI 名称不正确，则客户机应用程序将无法定位 JMS 目的地。d. ForeignJMSServer ForeignJMSServer 元素定义了一个 JNDI 提供者，它位于 WebLogic JMS 服务器外，是 ForeignJMSConnectionFactory 和 ForeignJMSDestination 元素的父元素。总之，这些元素提供了使 WebLogic Server 能够连接到远程 JNDI 提供者的信息，以便客户机可以使用本地的 JNDI 名称来指向远程连接工厂和目的地对象。您在使用 WebSphere MQ 作为 JMS 提供者时将会经常看到这一点。以下取自 config.xml 文件的代码片段显示一个外部 JMS 服务器、一个外部 JMS 连接工厂和两个外部 JMS 目的地： 此配置中的外部服务器、连接工厂和目的地将映 射到 WebSphere MQ JMS 提供者。正确配置 LocalJNDINames 和 RemoteJNDINames 是很重要的。e. JDBCConnectionPool 和 JDBCDataSource JDBCConnectionPool 和 JDBCTxDataSource 元素定义了 JDBC 资源的配置。以下取自 config.xml 文件的代码片段显示了单个连接工厂和数据源的配置： 在此代码中：o JDBCConnectionPool 元素定义了当对数据源调用 getConnection 时从连接池中返回的属性连接。o JDBCTxDataSource 元素定义了一个启用事务的 JDBC 数据源，并指定绑定数据源的 JNDI 名称和与此数据源相关联的连接池。要映射连接池和数据 源到 WebSphere Application Server，需要配置 JDBC 提供者、JDBC 数据源和 JCA 身份验证数据项。其中最重要的元素是 JNDIName、DriverName、URL、PasswordEncrypted 和 Properties。（您需要从数据库管理员那里获得密码，因为它在 config.xml 文件中是加密的。）要映射 TestTableName 属性，请使用名称为 PreTest SQL 字符串的 WebSphere 属性，在这里您可以设置一条 SQL 语句来测试每个 JDBC 连接。您还可以设置连接的重试时间间隔。您还应该根据“InitialCapacity”和“MaxCapacity”元素配置池大小。在缺省情 况下，WebSphere Application Server 连接池最少为一个连接，最多为十个连接。WebLogic 连接池配置为初始有 25 个连接，所以您需要配置 WebSphere 池大小。要完成此任务，请执行以下操作：3. 打开 WebSphere Application Server 管理控制台，选择 Resources = JDBC Providers。4. 选择提供者的名称。5. 选择 Additional Properties 下的 Data Sources 项。6. 单击数据源的名称。7. 选择 Connection pool properties。8. 使用 minimum and maximum connection 字段来配置池大小。还有其他一些特定于 WebLogic 的属性可以用来配置 JDBC 资源，但以上列出的属性是最常碰到的。映射 WebLogic 启动脚本本部分描述如何将这些服务器配置元素从 WebLogic 映射到 WebSphere Application Server：a. JVM 参数 b. 系 统参数 c. 类 路径 有关 WebLogic 配置元素的更多信息，请参阅参 考资料。a. JVM 参数 在自定义的启动脚本中指定 JVM 参数是很常见的 WebLogic 实践。请确保您获得了正确环境的正确启动脚本。下面是正在使用的 Sun JVM 选项的一个示例：-server -Xms1024m -Xmx1024m -verbose:gc -Xloggc:wls-gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:ParallelGCThreads=8 -XX:PermSize=128m -XX:MaxPermSize=128m假设您运行 WebSphere Application Server 所在的 JVM 正是针对 WebLogic 进行调整的那个 JVM，则以上扩展应该是针对 WebSphere Application Server 调整 JVM 的一个良好起点，但您可能会根据负载测试进行调整。要将这些 JVM 参数添加到 WebSphere Application Server，请执行以下操作：1. 从管理控制台中选择 Servers = Application Servers -= server_name = Process Definition = Java Virtual Machine。2. 选中 Verbose Garbage Collection（要记得将其关 闭）。3. 将 Initial Heap Size 设置为 1024。4. 将 Maximum Heap Size 设置为 1024。5. 添加 -server，作为 Generic JVM 参数框中的第一个参数，然后在现有的其他参数后面添加以下参数： -XX:ParallelGCThreads=8 -XX:PermSize=128m -XX:MaxPermSize=128m-Xloggc:wls-gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps6.牢记以下事项：o 详细垃圾回收是通过 -verbose:gc 选项启用的。在负载测试过程中收集垃圾回收统计数据是很有帮助的，但大大小小的每次回收都会被记录下来，所以请记住在运行最终的基准之前要禁用详细垃圾回 收。o 类垃圾回收在缺省情况下是启用的，它负责删除不再拥有任何活动实例的类。类垃圾回收在其 他 WebLogic 迁移中带来了性能和可伸缩性的问题，所以请通过添加此 JVM 参数来禁用它：-Xnoclassgc 有关调整 Sun 和其他 JVM 的更多信息，请参阅 Tuning Java virtual machines。b. 系统参数 在 WebLogic 启动脚本中指定的所有 -D 参数都应该映射到 WebSphere Application Server。没有成功映射系统参数非常有可能导致迁移问题。要将系统参数映射到 WebSphere Application Server ，请执行以下操作：1. 从管理控制台中选择 Application servers = server_name = Process Definition = Java Virtual Machine。2. 在这个示例中，启动脚本中有一个参数用于启用缓存，另一个参数用于指定 log4j 配置文件的位置。您应该将这些参数添加到 Generic JVM arguments 框中现有的所有 JVM 参数后面： -Dtangosol.coherence.distributed.localstorage=true -Dlog4j.configuration=file:/myprojects/config/log4j.xml3.c. 类路径 您经常会发现启动脚本中 WebLogic 类路径被修改。添加没有包含在企业存档中的 JAR，或者添加用于增加目录以便搜索应用程序所加载的配置文件的 JAR，都有可能修改类路径。在每种情况下，要映射它们，请执行以下操作：1. 从管理控制台中选择 Application servers = server_name = Process Definition = Java Virtual Machine。2. 在这个示例中，WebLogic 启动脚本添加了一个目录到类路径中，所以您也要将它添加到 WebSphere Application Server 类路径中。将此文件夹添加到 Classpath 框中： C:myprojects 向类路径添加 JAR 时要十分谨慎，只有在您确定它们没有包含在 WebSphere Application Server 分发中时才可以这样做。映射 weblogic-ejb-jar 元素本部分描述如何将这些服务器配置元素从 WebLogic 映射到 WebSphere Application Server：a. jndi-name b. local-jndi-name c. max-beans-in-free-pool 和 initial-beans-in-free-pool d. max-beans-in-cache 和 idle-timeout-seconds e. trans-timeout-seconds f. concurrency-strategy g. enable-call-by-reference h. cache-between-transactions i. delay-updates-until-end-of-tx j. finders-load-bean k. resource-description l. resource-env-description 有关 WebLogic 配置元素的更多信息，请参阅参 考资料。a. jndi-name jndi-name 元素在全局 JNDI 命名空间中指定EJB 的 JNDI 名称。要在 WebSphere Application Server 中设置 EJB 的 JNDI 名称，您需要知道 EJB 项目和正确的 EJB。要找到它们，请搜索 weblogic-ejb-jar 文件中的此元素： 要将 jndi-name 元素映射到 WebSphere Application Server，请执行以下操作：1. 启动组装工具，并打开 EJB 项目。2. 如果您使用的是 Rational Application Developer，请双击部署描述符。3. 单击适当的 EJB 组件。4. 向下滚动到 WebSphere Bindings 部分，键入该 bean 的 JNDI 名称。b. local-jndi-name local-jndi-name 元素在全局 JNDI 命名空间中定义 bean 本地 home 的 JNDI 名称。也就是说，WebLogic 提供了一种在全局 JNDI 命名空间中指定本地 home 的 JNDI 名称的方式但这样做使得远程客户机可以查找全局 JNDI 命名空间中的本地接口，这样会导致运行时错误，因为本地 home 必须在与客户机相同的容器中配置。现在，在进入 WebSphere 之前，请先了解一下 JNDI 的一些背景：o J2EE 规范并没有规定将 EJB 映射到全局 JNDI 命名空间中。而是留给供应商自己规定。因此，大多数供应商在他们自己的特定部署中包含了一个元素，用于在全局 JNDI 命名空间中指定远程 EJB JNDI 名称。o 然而，根据定义，本地 home 接口只能由本地容器访问，所以供应商不需要将它们绑定到全局 JNDI 命名空间中。虽然客户机模块可能使用 JNDI 查找本地 home，但容器不需要在 JNDI 命名空间中公开它们。相反，作为查找的一部分，客户机模块应该定义对 EJB 的 JNDI 引用，并在本地命名空间中使用 java:comp/env 来访问。o 建议您使用 JNDI 引用来访问本地命名空间中的 EJB，而不要使用 JNDI 名称来直接访问全局命名空间中的 EJB。使用 JNDI 引用可以杜绝客户机模块更改全局 JNDI 命名空间，这在支持同一 EJB 的多版本时是必需的。也就是说，使用相同 JNDI 引用的客户机模块可以绑定到新版本的 EJB 上而不需要修改任何源代码；客户机模块只是绑定其 JNDI 引用以指向不同的 EJB。了解了这些背景之后，如何将 local-jndi-name 元素映射到 WebSphere Application Server 呢？首先，需要知道 WebSphere Application Server 并没有提供为本地 home 定义 JNDI 名称的方式。相反，必须使用本地命名空间中的 JNDI 引用来访问本地 bean而不是全局命名空间中的 JNDI 名称。遗憾的是，一些 WebLogic 应用程序使用 JNDI 名称在全局 JNDI 命名空间中直接引用本地对象，而不是使用本地 JNDI 命名空间中的 JNDI 引用来间接引用它们。因此，必须对这些应用程序的代码进行一些更改。一些能够将 local-jndi-name 元素映射到 WebSphere Application Server 的方法是不受支持或者不实用的。但有一种方法可以使用，那就是向调用者模块添加本地 JNDI 引用（这是查找本地 home 的标准方式），然后在所有 JNDI 查找中使用 java:comp/env 前缀。不管访问 EJB 还是其他资源（例如 JMS 连接工厂），这种方式都是行业认可的最佳实践，所以它是您在这里应该使用的解决方案。c. max-beans-in-free-pool 和 initial-beans-in-free-pool max-beans-in-free-pool 元素定义了特定实体 bean、无状态会话 bean 或消息驱动 bean 的 EJB 空闲池的最大大小。每个 bean 类都可以使用此元素来定义自己的空闲池的大小。initial-beans-in-free-pool 元素定义了在启动时为特定 bean 类填充空闲池的 bean 实例的初始大小。用实例来填充空闲池可以提高初始响应时间，因为对该 bean 的初始请求不用生成新的实例即可得到满足。在 WebLogic 中，应用程序中的每个 bean 都可以指定最大的和初始的池大小，而不同的 bean 类的池大小会有很大的不同。要确定具体的池大小，请查看 weblogic-ejb-jar.xml 文件中的以下元素之一： 要在 WebSphere Application Server 中指定 EJB 池大小，可以在 JVM 中添加一个系统参数：1. 从管理控制台中选择 Application servers = server name = Process Definition = Java Virtual Machine。2. 将 com.ibm.websphere.ejbcontainer.poolSize 添加到 Generic JVM 参数框现有的所有 JVM 参数后面。这里是一个示例，它对名为 RuleEngineEJB 的 bean 设置了池大小最小为 1，最大为 5： -Dcom.ibm.websphere.ejbcontainer.poolSize=myapp#RulesEngine.jar#example.RulesEngineEJB=1,53.有关其他详细信息，请参阅 WebSphere EJB Container Tuning。虽然您可以映射池大小范围，但是应用程序服务器看待空闲池的方式是不同的：o 如果池是空的，WebLogic 将不会创建另一个实例；对新 bean 的请求只能等待，直到现有的 bean 返回到池中。如果池大小的分配不正确，这种策略可能导致死锁的情况，但是它控制了活动对象的数量，所以可能会对可伸缩性有所帮助。o 如果池是空的，WebSphere Application Server 将创建新的实例（而不是让请求在那等待）。在该请求使用新的实例后，WebSphere Application Server 只有在池中没有 maxSize bean 时才会将它返回到池中。（WebSphere Application Server 中的缺省池大小是最小 50，最大500。）注意这些区别是很重要的，因为在特定的情况下，如果负载过大而导致 bean 池被耗尽、对象创建成本太高或者消耗太多资源，则这些区别会导致 WebSphere Application Server 出现性能和可伸缩性问题。例如，考虑这种情况：o 一个应用程序实现了一个创建成本非常高的会话 bean。这种会话 bean 的一个例子是向在堆中缓存其规则基础（可能有几百兆数据）的规则引擎提供接口的会话 bean。o 由于这种 bean 创建成本太高，并且消耗堆中太多的可用空间，所以应用程序限定空闲池中 bean 的最大数目为 5，实际上也就限定了任何给定时间下此类 bean 不超过 5 个。o 应用程序限定活动 bean 的数目是因为在负载过大的情况下，与频繁创建/销毁额外会话 bean 相比，通过 5 个活动会话 bean 实例为所有获得此“规则服务”的传入请求提供服务更加理想（从可伸缩性的角度看）。现在，您已将最小为 1，最大为 5 的池大小映射到 WebSphere Application Server。这种映射能够工作得很好，因为它的确将池大小限制在 5 之内，同时又没有将活动实例的数目限制为 5。如果有五个请求将这五个会话 bean 全部占用，则池将为空，但如果有第六个请求到来，并获得其中一个会话 bean，则会创建并使用第六个会话对象只是不返回到池中。在 WebLogic 中，获得第六个会话对象的请求将不得不等待其中一个活动 bean 返回到池中才能得到服务。正如您所看到的，池大小的这种直接映射会导致创建额外的会话 bean，在负载过大的情况下，这种创建和销毁额外 bean 的做法会带来可伸缩性问题。如果应用程序要求对活动 bean 的数目进行硬性限制，则 bean 将需要跟踪空闲池中 bean 的数量，如果没有可用的，就得等待活动 bean 完成。从本示例中可以了解到重要的一点是，在负载测试过程中，应该关注活动 bean 的最大数目以确保它们不会超出池的最大大小。如果超出，则需要将池的大小调大一些，以避免频繁创建和销毁对象；或者是对活动 bean 的数目进行硬性限制。d. max-beans-in-cache 和 idle-timeout-seconds max-beans-in-cache 元素控制在任何给定时间都是活动状态的类对象的最大数目。当达到 max-bean-in-cache 的值时，WebLogic 将钝化一些最近没有被客户机使用的 EJB。idle-timeout-seconds 元素指定 bean 驻留缓存中的最长时间。当超过这个时间时，如果缓存中 bean 的数目接近 max-beans-in-cache，则容器就会删除该 bean。（在 WebLogic 8.1 SP4 之前此元素被忽略。）在 WebLogic 中，您可以定义各个 bean 类的缓存。内存中的对象因类而异，空闲超时时间也因类而异。要查找自定义的缓存，请搜索 weblogic-ebj-jar.xml 中的以下元素之一： 在 WebSphere Application Server 中，您无法指定每个 bean 类的缓存大小或空闲超时时间（在 WebSphere Application Server 中称为清理间隔），但您可以指定在整个 EJB 容器中处于活动状态的实例的缓存大小和清理间隔。WebSphere Application Server 中的缓存大小类似于 max-beans-in-cache。它指定 EJB 容器内活动实例列表中的 bucket 数目。虽然一个 bucket 可以包含多个实例，但当活动实例的数目超过 bucket 数目（缓存大小）时，容器就会尝试通过将它们钝化到磁盘的方式来删除一些实例。因此，在典型的工作负载过程中，如果将缓存大小设置为预期的最大活动实例 数，则性能是最佳的。WebSphere Application Server 中的清理间隔类似于 idle-timeout-seconds。它指定容器每隔多长时间尝试将不使用的项从缓存中删除以将总项数减少到缓存大小。如果您遇到根据逐类原则调整 WebLogic 缓存大小的应用程序，则在调整 WebSphere EJB 缓存大小时应该将这些缓存大小考虑在内。有一个算法可以用来调 整容器的 EJB 缓存大小，它根据不同类型的 bean 来计算平均 EJB 缓存需求。如果应用程序中有大量实体 bean，则应该及时使用 max-beans-in-cache 元素的值来计算任何实例上的活动在容器中的 EJB 的预期最大值，并监控负载测试过程中的缓存以确保没有出现缓存溢出；也就是说，确保没有大量 ejbStore 被调用。这个操作是很重要的，因为 WebSphere Application Server 中缺省的最大缓存大小只有区区几千，而大量使用实体 bean 的应用程序可能已经指定的池大小就有几千。e. trans-timeout-seconds trans-timeout-seconds 元素指定 EJB 的容器启动事务的最大持续时间。如果一个事务的持续时间超过 trans-timeout-seconds，则 WebLogic EJB 容器将回滚该事务。您可以通过搜索所有 weblogic-ejb-jar.xml 文件中的如下元素来查看此扩展： WebSphere Application Server 提供了两种设置事务超时时间的方式。选项 1：如果所有 bean 都将事务超时时间设置为相同的值，则可以使用管理控制台来设置 WebSphere 事务服务中的最大事务超时时间。a. 从管理控制台中选择 Servers = Application servers = server_name = Container Services = Transaction Service。b. 将整个事务生命周期的超时时间设置为 30。选项 2：可以在部署描述符中为 bean 设置事务超时时间。要设置事务超时时间，请执行以下操作：c. 在 Rational Application Developer 中，对于每个 EJB 对象，双击其部署描述符。d. 双击具体的 bean 来设置事务超时时间。e. 将组件事务超时时间设置为 30。一般建议更改每个 bean 的部署描述符，而不是所有 bean 的事务服务。更改所有 bean 的事务超时时间会影响在容器中运行的所有应用程序。但如果应用程序对所有 bean 设置的事务超时时间都一样，并且在容器中只有该应用程序在运行，则在 WebSphere Application Server 事务服务中设置一次值比在每个 bean 中都设置值要简单。如果不是这种情况，则应该对每个 bean 都设置事务超时时间。f. concurrency-strategy concurrency-strategy 元素指定容器应该如何管理对