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

最新推荐文章于 2022-08-18 01:29:29 发布

cuxiong8996

最新推荐文章于 2022-08-18 01:29:29 发布

阅读量615

点赞数

文章标签：大数据数据库 python linux java

原文链接：https://www.ibm.com/developerworks/websphere/library/techarticles/0706_vines/0706_vines.html

版权

本文的目的是帮助您将Java™2平台企业版（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 ServerV6.x。此处的大多数信息也适用于WebLogic Server早期版本的迁移应用程序。

迁移服务器配置

迁移服务器配置实质上意味着将WebLogic Server的应用程序文件外部（但在域配置内部）中包含的设置移动到WebSphere Application Server。这些设置可以包括JMS连接工厂和目标，JDBC数据源，J2EE安全设置，邮件会话等等。

要迁移配置，您必须知道需要迁移哪些设置。但是，您很有可能没有关于这些设置的任何文档，也没有任何脚本（可能已用于创建服务器配置）供参考。如果是这种情况，则需要登录每个域中的WebLogic管理控制台以查找设置，以便可以确定需要在WebSphere Application Server环境中创建的设置。

但是，如果您无法（或不允许）访问WebLogic管理控制台怎么办？

无论哪种方式，收集WebLogic服务器配置信息的最有效方法是检查WebLogic域配置文件config.xml和WebLogic启动脚本。 WebLogic管理员通常会为您提供这些文件的副本，因为对其进行检查不会影响任何正在运行的系统。

WebLogic管理控制台是WebLogic config.xml文件的存储位置，它存储所有资源定义。无法正确映射这些资源可能会导致应用程序失败。
管理员通常会创建一个自定义的启动脚本 ，然后向其中添加系统属性，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命名空间的映射，以及各种与性能相关的设置，例如池大小，事务隔离级别，EBJ查询语言的扩展等等。 部署描述符描述了J2EE应用程序所需的执行环境，并且具有两个一般的变体：

本文不讨论Web服务的部署描述符，后续文章将介绍其映射。

行业标准部署描述符 （图2）是可移植的，通常不需要进行任何更改，但是WebLogic和WebSphere Application Server之间存在一些值得注意的差异。例如，IBM的标准部署描述符使用ID将标准描述符中的信息与特定于供应商的描述符中的信息相关联，而WebLogic则使用ejb-names进行相关性。因此，当您迁移WebLogic部署描述符并创建特定于IBM的描述符时，将需要向它们添加适当的ID。让您的组装工具（例如IBMRational®Application Developer）为您创建这些ID。如果尝试自己创建这些ID并弄错了，将很难解决错误。

图2.行业标准部署描述符
必须迁移特定于供应商的部署描述符 （图3）。图3显示了特定于WebLogic的部署描述符和相应的特定于WebSphere的部署描述符。

图3.特定于供应商的部署描述符

IBM提供了许多工具来帮助您将WebLogic部署描述符迁移到WebSphere Application Server，包括：
- Xdoclet标签
- WebSphere Rapid Deployment标签
- 应用程序服务器工具包（部署描述符编辑器）
- 用于Rational Application Developer V6的IBM J2EE竞争性迁移器插件。
请参阅将应用程序从WebLogic，JBoss和Tomcat迁移到WebSphere V6，以了解这些工具的作用，如何以及何时使用它们，在哪里获得帮助等等。重要的是要了解这些工具，并在适当的时候使用它们。尽管这些工具将映射特定于供应商的部署描述符中的某些扩展，但它们不会映射所有扩展，因此对于您而言，检查部署描述符并知道如何映射在其中找到的扩展对于您而言仍然很重要。基于这种理解，使用像Application Server Toolkit这样的组装工具可能会非常有效。

映射config.xml元素

本部分描述如何将这些服务器配置元素从WebLogic映射到WebSphere Application Server：

有关每个元素的更多详细信息，请参阅《 WebLogic Server配置参考》。

JMSConnectionFactory

JMSConnectionFactory元素创建一个连接工厂对象，并将其绑定到JNDI名称空间。在config.xml文件中为此应用程序配置了三个连接工厂。每个都启用了XA：
```
<JMSConnectionFactory 
      JNDIName="jms/Operations"
      Name="Operations" Targets="myserver" 
      XAConnectionFactoryEnabled="true"
/>

<JMSConnectionFactory 
      JNDIName="jms/Mailing"
      Name="Mailing" Targets="myserver" 
      XAConnectionFactoryEnabled="true"
/>

<JMSConnectionFactory 
      JNDIName="jms/Administration"
      Name="Administration" Targets="myserver" 
      XAConnectionFactoryEnabled="true"
/>
```
要将此配置映射到WebSphere Application Server，通常需要在WebSphere默认消息传递提供程序中创建上面显示的JMS连接工厂。其他一些预防措施包括：
- 在WebSphere Application Server中配置这些JMS连接工厂时，请使用正确的JNDIName。如果JNDI名称不正确，则应用程序将无法找到连接工厂。
- 通过为指定事务属性“ NotSupported”的非事务性MDB禁用XA，来验证消息驱动bean（MDB）是否是事务性的，因为可能会提高性能。非事务性MDB不能参与XA事务，并且不需要启用XA的连接工厂。另一方面，如果MDB将事务属性指定为“必需”，则应为XA的connection-factory-jndi-name启用。
- 在WebSphere Application Server中创建连接工厂时，默认情况下会启用XA。
JMSFileStore

JMSFileStore元素定义了一个基于磁盘的JMS文件存储，该文件存储在文件系统目录中存储持久消息（用于队列）和持久订户（用于主题）。此代码片段显示了单个JMS文件存储的定义：
```
<JMSFileStore 
      Directory="/log//weblogic/wl-myserver/rmfilestore"
      Name="FileStoreMailing" SynchronousWritePolicy="Cache-Flush"
/>
```
要将此配置映射到WebSphere Application Server，首先需要知道WebSphere Application Server V6.0缺省消息传递不支持JMS文件存储。文件存储是6.1版中的增强功能，但是如果使用的是6.0版，则需要为消息传递引擎定义JDBC数据源。
JMS服务器

JMSServer元素定义一个JMS服务器，该服务器管理到其JMS目标的连接和消息（指的是JMSQueue或JMSTopic元素）。 config.xml文件中的此代码片段显示了三个JMS服务器，每个服务器包含两个JMS目标，这里使用JMS队列：
```
<JMSServer Name="JMSServerOperations" Targets="myserver">
      <JMSQueue CreationTime="1149493675734"
            JNDIName="jms/Queue/EntryOperations" 
            Name="EntryOperations"/>
      <JMSQueue CreationTime="1161679692974"
            JNDIName="jms/Queue/ExitOperations" 
            Name="ExitOperations"/>
</JMSServer>

<JMSServer Name="JMSServerMailing" 
              Store="FileStoreMailing" Targets="myserver">
      <JMSQueue CreationTime="1161682828610"
            JNDIName="jms/Queue/RequestEntryMailing" 
            Name="RequestEntryMailing"/>
<JMSQueue CreationTime="1161682915323"
      JNDIName="jms/Queue/RequestMailing" 
      Name="RequestMailing"/>
</JMSServer>

<JMSServer Name="JMSServerAdministration" Targets="myserver">
      <JMSQueue CreationTime="1161683412185"
            JNDIName="jms/Queue/EntryAdministration" 
            Name="EntryAdministration"/>
      <JMSQueue CreationTime="1161683429724"
            JNDIName="jms/Queue/ExitAdministration" 
            Name="ExitAdministration"/>
</JMSServer>
```
在此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目标。
国外JMSServer

ForeignJMSServer元素定义一个JNDI提供程序，该提供程序位于WebLogic JMS服务器外部，并且是ForeignJMSConnectionFactory和ForeignJMSDestination元素的父元素。这些元素一起提供使WebLogic Server能够访问远程JNDI提供程序的信息，以便客户端可以使用本地JNDI名称来引用远程连接工厂和目标对象。使用WebSphere MQ作为JMS提供程序时，您经常会看到这种情况。 config.xml文件中的以下代码片段显示了一个外部JMS服务器，一个外部JMS连接工厂和两个外部JMS目标：
```
<ForeignJMSServer ConnectionURL="file:/var/mqm/qmgrs"
      InitialContextFactory="com.sun.jndi.fscontext.RefFSContextFactory"
      JNDIProperties="" Name="JMSServerMailingMq" Targets="myserver">
      <ForeignJMSConnectionFactory
            LocalJNDIName="jms/MailingMq"
            Name="MailingMq" 
            RemoteJNDIName="MYSERVER"/>
      <ForeignJMSDestination
            LocalJNDIName="jms/Queue/RequestMailingMq"
            Name="RequestMailingMq" 
            RemoteJNDIName="J2EE_MVS_OFF_IN"/>
      <ForeignJMSDestination
            LocalJNDIName="jms/Queue/RespuestaMailingMq"
            Name="RespuestaMailingMq" 
            RemoteJNDIName="J2EE_MVS_OFF_OU"/>
</ForeignJMSServer>
```
此配置中的外部JMS服务器，连接工厂和目的地将映射到WebSphere MQ JMS provider 。正确配置LocalJNDINames和RemoteJNDINames非常重要。
JDBCConnectionPool和JDBCDataSource

JDBCConnectionPool和JDBCTxDataSource元素定义JDBC资源的配置。 config.xml文件中的以下代码片段显示了单个连接池和数据源的配置：
```
<JDBCConnectionPool DriverName="oracle.jdbc.driver.OracleDriver"
                    Name="MyJDBCConnectionPool"
                    PasswordEncrypted="{3DES}B2Bl+tp70Eh3D1pT53/anw=="
                    Properties="user=wles" Targets="myserver"
                     URL="jdbc:oracle:thin:@localhost:1521:ASI"
                     InitialCapacity="25" MaxCapacity="125"
                     TestTableName="SQL SELECT 1 FROM DUAL"/>
  <JDBCTxDataSource JNDIName="jdbc/MyDataSource"
                    Name="MyJDBCDataSourceName"
                    PoolName="MyJDBCConnectionPool"
                     Targets="myserver"/>
```
在此代码中：
- JDBCConnectionPool元素定义在数据源上调用getConnection时从池返回的属性连接。
- JDBCTxDataSource元素定义了启用了事务的JDBC数据源，并指定了绑定数据源的JNDI名称以及与此数据源关联的连接池。
要将连接池和数据源映射到WebSphere Application Server，请配置JDBC提供程序，JDBC数据源和JCA认证数据条目。最重要的元素是JNDIName，DriverName，URL，PasswordEncrypted和Properties。（您将需要从数据库管理员那里获取密码，因为该密码已在config.xml文件中加密。）

要映射TestTableName属性，请使用称为PreTest SQL string的WebSphere属性，您可以在其中设置一个SQL语句来测试每个JDBC连接。您还可以设置连接重试间隔。

您还应该基于<InitialCapacity>和<MaxCapacity>元素配置池大小。缺省情况下，WebSphere Application Server连接池将具有最少一个连接和最多十个连接。 WebLogic连接池配置为从25个连接开始，因此您将需要配置WebSphere池大小。要做到这一点：
1. 打开WebSphere Application Server管理控制台，然后选择Resources => JDBC Providers 。
2. 选择提供者的名称。
3. 在其他属性下选择数据源条目。
4. 单击数据源名称。
5. 选择连接池属性 。
6. 使用最小和最大连接字段来配置池的大小。

还有其他一些WebLogic特定的属性可用于配置JDBC资源，但是上面列出的那些是最常遇到的。

映射WebLogic启动脚本

本部分描述如何将这些服务器配置元素从WebLogic映射到WebSphere Application Server：

请参阅相关主题有关WebLogic配置元素的更多信息。

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
```
假设您将在针对WebLogic调整的同一JVM上运行WebSphere Application Server，那么上述扩展应该是为WebSphere Application Server调整JVM的良好起点，但是您可能希望根据负载测试对其进行调整。要将这些JVM参数添加到WebSphere Application Server：
1. 从amin控制台中，选择服务器=>应用程序服务器-=> server_name =>进程定义=> Java虚拟机 。
2. 检查详细垃圾收集 （切记将其关闭）。
3. 将初始堆大小设置为1024 。
4. 将“最大堆大小”设置为1024 。
5. 在通用JVM参数框中将-server添加为第一个参数，然后在其他现有参数之后添加以下参数：
```
-XX:ParallelGCThreads=8 
-XX:PermSize=128m 
-XX:MaxPermSize=128m
-Xloggc:wls-gc.log  
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps
```
注意事项：
- 详细垃圾回收是通过-verbose:gc选项启用的。在负载测试期间收集垃圾收集统计信息非常好，但是将记录每个主要和次要垃圾收集，因此请记住在运行最终基准之前禁用详细垃圾收集。
- 默认情况下，启用类垃圾回收，当没有剩余的活动实例时，该类将删除类。类垃圾回收在其他WebLogic迁移中导致了性能和可伸缩性问题，因此请通过添加以下JVM参数将其禁用：
  
  -Xnoclassgc
有关调整Sun和其他JVM的其他信息，请参见调整Java虚拟机。
系统参数

WebLogic启动脚本中指定的所有-D参数都应映射到WebSphere Application Server。未能映射系统参数肯定会导致迁移问题。要将系统参数映射到WebSphere Application Server：
1. 在管理控制台中，选择“ 应用程序服务器=> server_name =>进程定义=> Java虚拟机” 。
2. 在此示例中，启动脚本具有一个启用缓存的参数和另一个指定log4j配置文件位置的参数。您应该将这些参数添加到所有现有JVM参数之后的“ 通用JVM参数”框中：
```
-Dtangosol.coherence.distributed.localstorage=true 
-Dlog4j.configuration=file:///myprojects/config/log4j.xml
```
类路径

您通常会发现在启动脚本中已修改了WebLogic类路径。这样做可能是为了添加JAR，这些JAR要么不包含在应用程序的企业归档中，要么用于添加目录，以搜索由应用程序加载的配置文件。要在两种情况下映射它们：
1. 在管理控制台中，选择“ 应用程序服务器=> server_name =>进程定义=> Java虚拟机” 。
2. 在此示例中，WebLogic启动脚本将目录添加到类路径，因此您也将其添加到WebSphere Application Server类路径。将此文件夹添加到“ 类路径”框中：
  C:\myprojects
  
  在将JAR添加到类路径时要小心，只有在确保它们尚未包含在WebSphere Application Server发行版中时，才这样做。

映射weblogic-ejb-jar元素

本部分描述如何将这些服务器配置元素从WebLogic映射到WebSphere Application Server：

请参阅相关主题有关WebLogic配置元素的更多信息。

英文名

jndi-name元素在全局JNDI名称空间中指定EJB的JNDI名称。要在WebSphere Application Server中设置EJB的JNDI名称，您需要知道EJB项目和正确的EJB。要找到它们，请在weblogic-ejb-jar文件中搜索以下元素：

<jndi-name>

要将jndi-name元素映射到WebSphere Application Server：
1. 启动组装工具，然后打开EJB项目。
2. 如果使用的是Rational Application Developer，则双击部署描述符。
3. 单击适当的EJB组件。
4. 向下滚动至WebSphere Bindings部分，然后输入该bean的JNDI名称。
本地名称

local-jndi-name元素在全局JNDI名称空间中为bean的本地宿主定义JNDI名称。也就是说，WebLogic提供了一种在全局JNDI命名空间中为本地宿主指定JNDI名称的方法-但这使远程客户端可以在全局JNDI命名空间中查找本地接口，这可能导致运行时错误，因为本地宿主必须与客户端放置在同一容器中。现在，在研究WebSphere方面之前，请考虑JNDI的背景：
- J2EE规范未指定EJB到全局JNDI名称空间的映射。这由供应商决定。因此，大多数供应商在自己的特定部署中都包含一个元素，以在全局JNDI名称空间中指定远程EJB JNDI名称。
- 但是，根据定义，本地本地接口只能由本地容器访问，因此供应商不需要将它们绑定到全局JNDI名称空间。尽管客户端模块可以使用JNDI查找本地房屋，但是容器无需在JNDI名称空间中公开它们。相反，客户端模块应该定义对EJB的JNDI引用，并使用java：comp / env作为查找的一部分在本地名称空间中对其进行访问。
- 业界建议您使用JNDI引用访问本地名称空间中的EJB，而不是使用JNDI名称直接在全局名称空间中访问EJB。使用JNDI引用可将客户端模块与对全局JNDI名称空间的更改隔离开，这是支持同一EJB的多个版本所必需的。也就是说，可以将使用相同JNDI引用的客户端模块绑定到EJB的新版本，而无需修改任何源代码。客户端模块仅将其JNDI引用绑定为指向另一个EJB。
现在，在这种背景下，如何将local-jndi-name元素映射到WebSphere Application Server？

首先，您需要了解WebSphere Application Server没有提供一种为本地家庭定义JNDI名称的方法。相反，您必须使用本地名称空间中的JNDI引用访问本地bean，而不是全局名称空间中的JNDI名称。

不幸的是，某些WebLogic应用程序使用JNDI名称直接在全局JNDI名称空间中引用本地对象，而不是使用本地JNDI名称空间中的JNDI引用间接引用它们。因此，这些应用程序将需要一些代码更改。您可以通过几种方法将local-jndi-name元素映射到WebSphere Application Server，这是不支持的或不可行的。但是您可以使用的一种方法是将本地JNDI引用添加到调用方模块（这是查找本地房屋的标准方法），然后在所有JNDI查找中使用java：comp / env前缀。这是业界公认的最佳实践，不仅可以访问EJB，而且可以访问其他资源（例如JMS连接工厂），因此这是您应在此处使用的解决方案。
空闲池中的最大beans和空闲池中的初始beans

max-beans-in-free-pool元素定义特定实体bean，无状态会话bean或消息驱动bean的EJB空闲池的最大大小。每个bean类都可以使用此元素定义其自己的空闲池的大小。

initial-beans-in-free-pool元素定义启动时将填充特定bean类的空闲池的bean实例的初始数量。用实例填充空闲池可改善初始响应时间，因为可以满足对Bean的初始请求，而无需生成新实例。

在WebLogic中，应用程序中的每个bean都可以指定其最大池大小和初始池大小，并且从一个bean类到下一个bean类，池大小可以有很大不同。要确定特定的池大小，请在weblogic-ejb-jar.xml文件中查找以下元素之一：

<initial-beans-in-free-pool> <max-beans-in-free-pool>

要在WebSphere Application Server中指定EJB池大小，可以将系统参数添加到JVM：
1. 在管理控制台中，选择“ 应用程序服务器=>服务器名称=>进程定义=> Java虚拟机” 。
2. 将com.ibm.websphere.ejbcontainer.poolSize添加到所有现有JVM参数之后的“通用JVM参数”框中。这是一个示例，该示例将名为RuleEngineEJB的bean的池大小最小设置为1，最大设置为5：
```
-Dcom.ibm.websphere.ejbcontainer.poolSize
=myapp#RulesEngine.jar#example.RulesEngineEJB=1,5
```
请参阅WebSphere EJB容器调整以获取更多详细信息。

尽管可以映射池大小扩展，但是应用程序服务器对空闲池的处理方式有所不同：
- 如果池为空，WebLogic将不会创建另一个实例；对新bean的请求将必须等待，直到将现有bean返回到池中为止。如果池的大小不正确，则此策略可能导致死锁情况，但它控制活动对象的数量，这可能有助于扩展性。
- 如果池为空，WebSphere Application Server将创建一个新实例（而不是等待该请求）。请求使用该新实例之后，如果池中还没有maxSize bean，则WebSphere Application Server仅将其返回到池中。（WebSphere Application Server中的缺省池大小最小为50，最大为500。）
重要的是要注意这些差异，因为在某些情况下，如果Bean池在高负载下耗尽，创建对象的成本很高或消耗的资源过多，它们可能会导致WebSphere Application Server中的性能和可伸缩性问题。。例如，考虑这种情况：
- 应用程序实现了一个会话Bean，该会话Bean创建起来非常昂贵。此类会话bean的一个示例可能是为规则引擎提供接口，该引擎在堆中缓存其规则库（可能是数百兆字节的数据）。
- 由于此bean的创建成本很高，并且占用了堆中的大量可用空间，因此应用程序将空闲池中的bean的最大数量限制为5，这实际上在任何给定条件下将此类bean的数量限制为5时间。
- 该应用程序限制了活动bean的数量，因为从5个活动会话bean实例（从可伸缩性的角度来看）更好地为该“规则服务”的所有传入请求提供服务，而不是在重负载下连续创建/销毁其他会话bean 。
现在，您可以将此池大小（最小为1，最大为5）映射到WebSphere Application Server。映射工作正常，因为它确实将池大小限制为5，但没有将活动实例的数目限制为5。如果使用所有五个会话Bean的请求数为5，则该池将为空，但是，如果对这些会话bean中的一个请求第六个请求，那么将创建并使用第六个会话对象-只是不返回到池中。在WebLogic中，对第六个会话对象的请求必须先等待其中一个活动bean返回池，然后才能继续。

如您所见，池大小的这种直接映射可能导致创建其他会话bean，而在繁重的负载下，其他bean的创建和销毁可能导致可伸缩性问题。如果应用程序要求对活动会话数进行硬性限制，那么该bean将需要跟踪空闲池中的bean数量，并在没有可用活动时等待一个活动bean完成。

从该示例中可以汲取的重要教训是，在负载测试期间，您将需要关注活动中的最大bean数，以确保它们不超过池的maxSize。如果这样做，则可能需要将池的大小调整为更大，以避免连续创建和销毁对象。否则，您将要对活动bean的数量实施硬性限制。
缓存中的最大豆数和空闲超时秒数

max-beans-in-cache元素控制可以在任何给定时间处于活动状态的此类的最大对象数。当达到max-bean-in-cache的值时，WebLogic会钝化客户端最近未使用的某些EJB。

idle-timeout-seconds元素指定Bean保留在高速缓存中的最长时间。经过此时间后，如果缓存中的Bean数量接近缓存中的max-beans，则容器将删除Bean。（在WebLogic 8.1 SP4之前，此元素被忽略。）

在WebLogic中，可以为单个bean类定义缓存。可以在内存中的对象随类的不同而不同，空闲超时也可以。要查找自定义的缓存，请在weblogic-ebj-jar.xml中搜索以下元素之一：

<max-beans-in-cache> <idle-timeout-seconds>

使用WebSphere Application Server，您不能为每个bean类指定高速缓存大小或空闲超时（在WebSphere Application Server中称为清除间隔 ），但是可以为可以在整个EJB中处于活动状态的实例指定高速缓存大小和清除间隔。容器。

WebSphere Application Server中的高速缓存大小类似于max-beans-in-cache。它在EJB容器内的活动实例列表中指定存储桶的数量。尽管一个存储桶可以包含多个实例，但是当活动实例的数量超过存储桶的数量（高速缓存大小）时，容器会通过将某些实例钝化到磁盘上而疲倦地删除它们。因此，如果将缓存大小设置为典型工作负载期间预期的最大活动实例数，则性能最佳。

WebSphere Application Server中的清理间隔类似于idle-timeout-seconds。它指定容器尝试从缓存中删除未使用的项目的时间间隔，以将缓存中的项目总数减少到缓存大小的值。

如果遇到某个应用程序，其中逐级对WebLogic缓存大小进行了调整，则在调整WebSphere EJB缓存大小时应考虑这些缓存大小。您可以使用一种算法来调整容器的EJB缓存大小，该算法可根据不同种类的bean计算平均EJB缓存需求。

如果应用程序中有大量实体Bean，则应使用max-beans-in-cache元素的值在任何时候及时计算容器中活动的EJB的预期最大值，并在操作期间监视缓存。进行负载测试以验证是否没有从缓存中逐出；也就是说，确保没有很高的ejbStores调用率。此操作很重要，因为WebSphere Application Server中的默认最大高速缓存大小只有几千，并且大量使用实体bean的应用程序可能已经指定了几千的池大小。
跨超时秒

trans-timeout-seconds元素指定EJB的容器启动的事务的最大持续时间。如果事务持续的时间超过trans-timeout-seconds，则WebLogic EJB容器将回滚事务。通过在所有weblogic-ejb-jar.xml文件中搜索此元素，可以看到此扩展名：

<trans-timeout-seconds>

WebSphere Application Server提供了两种设置事务超时的方法。

选项1：如果所有Bean都将事务超时设置为相同的值，那么可以使用管理控制台在WebSphere事务服务中设置最大事务超时：
1. 从管理控制台中，选择服务器=>应用程序服务器=> server_name =>容器服务=>事务服务 。
2. 将“总事务生存期超时”设置为30 。
选项2：您可以在Bean的部署描述符中设置事务超时。要做到这一点：
1. 在Rational Application Developer中，对于每个EJB项目，双击其部署描述符。
2. 双击特定的bean设置事务超时。
3. 将“组件事务超时”整数设置为30 。
一般建议是更改Bean的部署描述符，而不是更改所有Bean的事务服务。更改所有bean的事务超时将影响该容器中运行的所有应用程序。 But if the application sets the transaction timeout to the same value in all beans, and is the only application running in that container, then it will be much easier to set that value once in the WebSphere Application Server transaction service instead of in each bean. If this is not the case, then you should set the transaction timeout for each bean.
concurrency-strategy

The concurrency-strategy element specifies how the container should manage concurrent access to an entity bean. WebLogic supports four different consurrency strategies:
- Exclusive concurrency strategy causes WebLogic Server to place an exclusive lock on cached entity EJB instances when the bean is associated with a transaction. Other requests for the EJB instance are blocked until the transaction completes.
  
  To find the beans that use the Exclusive concurrency strategy, search the weblogic-ejb-jar.xml files for this element:
  
  <concurrency-strategy>Exclusive</concurrency-strategy>
  
  When you find them, note their EJB project and EJB name, which you will need to map them to WebSphere Application Server:
  1. In Rational Application Developer, open the EJB project.
  2. Double click on the deployment descriptor.
  3. Double click on the appropriate Java bean.
  4. Scroll down to the Bean Cache section.
  5. Set Activate at to ONCE .
  6. Set Load at to ACTIVATION .
  These parameters avoid calls to the ejbLoad function, but serializes access to the bean instance. This option increases memory utilization by maintaining persistent state in the cache but can provide better response time if the bean instance is not generally accessed concurrently. This option is referred to as caching Option A in the EJB specification.
- ReadOnly concurrency strategy is used for read-only entity beans. It activates a new instance for each transaction so that requests proceed in parallel. When WebLogic Server calls ejbLoad() for ReadOnly beans, it is based on the <read-timeout-seconds> element.
  
  The read-timeout-seconds element specifies the number of seconds between ejbLoad() calls on a read-only entity bean. It only applies to those beans with a ReadOnly concurrency strategy. A read-timeout-seconds with a value of 0 specifies that the read-only bean is not to be reloaded from the database.
  
  To find the read-only beans, search the weblogic-ejb-jar.xml files for this element:
  
  <concurrency-strategy>ReadOnly</concurrency-strategy>
  
  Again, be sure to note the EJB project and EJB names so you can mark them as read-only beans in WebSphere Application Server:
  1. In Rational Application Developer, open the EJB project.
  2. Double click on the deployment descriptor.
  3. Double click on the appropriate Java bean.
  4. Scroll down to the Bean Cache section.
  5. Set Activate at to ONCE .
  6. Set Load at to INTERVAL .
  7. Set Reload interval integer to the appropriate number of minutes. (For example, if the WebLogic <read-timeout-seconds> element was set to 600 seconds, then you would set the reload interval integer to 10 minutes for WebSphere Application Server.)
  If <read-timeout-seconds> is set to 0 in WebLogic, then ejbLoad is called only when the instance is first brought into the cache. In WebSphere Application Server, a Reload integer interval value of 0 also causes the container to never reload the bean.
  
  (See Related topics for more information on developing read-only beans in WebSphere Application Server.)
- Database concurrency strategy causes WebLogic Server to delegate locking requests for an entity bean to the underlying datastore. With this strategy, WebLogic Server allocates a separate entity bean instance and enables locking and caching to be handled by the database. 这是默认选项。
  
  The WebLogic Database concurrency strategy implies that the bean is activated and added to the cache at the beginning of a transaction, and is passivated and removed form the cache at the end of the transaction.
  
  To find the EJB components and projects that use the Database concurrency strategy, search the weblogic-ejb-jar.xml files for this element:
  
  <concurrency-strategy>Database</concurrency-strategy>
  
  Again, note the EJB project and the EJB name. To map the Database concurrency strategy to WebSphere Application Server:
  1. In Rational Application Developer, open the EJB project.
  2. Double click on the deployment descriptor.
  3. Double click on the appropriate Java bean.
  4. Scroll down to the Bean Cache section.
  5. Set Activate at to TRANSACTION .
  6. Set Load at to TRANSACTION .
  The default for the WebSphere Application Server V6.0 bean cache is Activate at: transaction and Load at: transactions -- since this is the default, you don't have to explicitly set it for each of the beans that you want to have the Database concurrency strategy. This strategy is also referred to as caching Option C in the EJB specification.
- Optimistic concurrency strategy holds no locks in the EJB container or database during a transaction. The EJB container verifies that none of the data updated by a transaction has changed before committing the transaction. If any updated data changed, the EJB container rolls back the transaction.
  
  To find the beans that support Optimistic concurrency control, search the weblogic-ejb-jar.xml files for this element:
  
  <concurrency-strategy>Optimistic</concurrency-strategy>
  
  Be sure to note that EJB project and the EJB name. You'll need those values to migrate the database concurrency strategy.
  
  Once you have found those beans and have noted their names and the names of their EJB projects, search the weblogic-cmp-rdbms-jar.xml for the <verify-columns> element; these columns in the table are the ones you need to validate before committing it to the database, making sure no other transaction has modified the data.
  
  Now you are ready to configure Optimistic concurrency in WebSphere Application Server.
  1. First, enable optimistic locking in the deployment descriptor:
    1. In Rational Application Developer, open the EJB project.
    2. Double click on the deployment descriptor.
    3. Select the Access tab.
    4. For Access Intent for Entities 2.x (Bean Level), select the EJB and press the Add button.
    5. For Access Intent name, select wsOptimisticUpdate and press the Finish button.
  2. Next, specify the field(s) to include in the overqualified update statement when modified data is committed. To do this, you should have database maps defined for your EJB to DDB mapping. When this is done:
    1. Right click on the EJB project.
    2. Select EJB to RDB Mapping => Generate Map .
    3. In the Enterprise Beans pane of the Overview section, select the CMP field that should be used as an optimistic predicate to be included in the overqualified SQL update statement.
    4. In the Properties view, select True for the OptimisticPredicate.
enable-call-by-reference

The enable-call-by-reference element is generally used to pass parameters by reference rather than by value, which requires making a copy of the parameters. When enable-call-by-reference is True, EJB methods called from within the same EAR file or standalone JAR file will pass arguments by reference, which improves method invocation performance since parameters are not copied.

In WebLogic, you can enable call by reference on a bean-by-bean basis, but with WebSphere Application Server, you can enable call by reference at the container level. Therefore, if call by reference is enabled, it applies to all of the remote interfaces in the application, not only to a subset of them.

To enable call by reference in WebSphere Application Server:
1. From the admin console, select Servers => Application servers => server_name => Container services => ORB Services .
2. Check Pass by reference .
cache-between-transactions

The cache-between-transactions element specifies whether or not the EJB container will cache the persistent state of an entity bean between transactions. Specify True to enable the caching of persistent state between transactions; specify False (the default) to not cache persistent state between transactions.

Whether or not you can cache-between-transactions depends on the concurrency strategy:
- If the concurrency strategy is ReadOnly, then the persistent state will always be cached between transactions.
- If the concurrency-strategy is Database then the persistent state is never cached between transactions.
Therefore, if the entity uses the ReadOnly or Database concurrency strategy, the cache-between-tansactions elements is actually ignored by the EJB container for those beans.

With WebSphere Application Server, there is no need to map the cache-between-transactions element because WebSphere Application Server's implementation of read-only beans always caches persistent state between transactions, and the implementation of the Database concurrency strategy never caches persistent state. This is the same behavior you get with WebLogic.
delay-updates-until-end-of-tx

The delay-updates-until-end-of-tx element is set to True by default to update the persistent store of all beans in a transaction when the transaction completes. This is consistent with batching all database operations until the end of the transaction, which is also the WebLogic default. If you set this element to False, then updates are written to the database each time a CMP EJB set method is called. Generally, setting it to True improves performance, but this does not preserve the ordering of database updates within a database transaction.

In the WebLogic application, you might find some beans that specify False for delay-updates-until-end-of-tx. Presumably, this overides the default WebLogic setting of defering all database operations until the end of the transaction. To find the beans that turn off defer updates until the end of the transaction, search the weblogic-ejb-jar.xml files for the this element:

<delay-updates-until-end-of-tx>false</delay-updates-until-end-of-tx>

In WebSphere Application Server, the default is to perform database operations when each CMP mutator is called, rather than delay them to the end of the transaction. You can delay updates until the end of the transaction in WebSphere Application Server for performance optimization, but you can only turn it on or off for all beans in the container.

When you delay updates until the end of the transaction, you generally improve performace; the tradeoff is that batching operations does not execute the updates in the same order they were executed in the code. For additional considerations, see enable-batch-operations and order-database-operations .
finders-load-bean

The finders-load-bean element determines whether WebLogic Server loads the EJB into the cache after a call to a finder method that returns a reference to the bean. If you set this element to True (the default) and a reference to a bean is returned by the finder, then WebLogic Server immediately loads the bean into the cache. If you set this element to False, WebLogic Server does not automatically load the bean into the cache until the first method invocation.

In WebSphere Application Server, the default is to load the beans into the cache when the finder is called, as this behavior is consistent with the CMP 2.0 specification. If you want to change this behavior to defer loading beans into the cache until the first method is called, you can define the EJB JAR that contains those EJBs to implement the EJB1.1 specification, as this behavior is consistent with that specification.
resource-description

The resource-description element maps a <resource-ref> defined in ejb-jar.xml to the JNDI name of the actual resource. Typical examples of <resource-ref> elements that are defined in the ejb-jar.xml file are JDBC data sources and JMS connection factories. You can find the actual JNDI name of those resources in the WebLogic config.xml file.

Using the <resource-description> element enables the client to bind the logical name of a resource to the actual JNDI name for that resource. The client looks up the resource using the logical JNDI reference in the local namespace (for example, java:comp/env/<res-ref-name>) instead of the actual JNDI name (for example, <jndi-name>), which isolates the client from changes to the JNDI name.

In WebLogic, the mapping of resources to JNDI names is specified in the weblogic-ejb-jar.xml file; 例如：
```
<resource-description>
      <res-ref-name>jms/Mailing</res-ref-name>
      <jndi-name>jms/Mailing</jndi-name>
</resource-description>
```
In WebSphere Application Server, the mapping of resources to JNDI names is specified using an assembly tool:
1. In Rational Application Developer, open the appropriate EJB project; for example: ShippingAutoserviceEJB .
2. Double click on the deployment descriptor.
3. Click on the References tab.
4. Expand the correct Java Bean (such as ShipmentManager ) to see all of the JNDI resource references. You will need to specify a JNDI name for each reference. Select one of the references, such as jms/MailingMq . (WebLogic treats the mapping of <resource-ref> to JNDI name differently than the mapping of <resource-env-ref> to JNDI names (see the next section), but WebSphere Application Server treats them the same. Thus, when you expand the Java bean, you will see all <resource-ref> and <resource-env-ref> defined in the ejb-jar.xml file for that bean.)
5. Scroll down to the WebSphere Bindings section and enter the correct JNDI name for that resource (found in the WebLogic config.xml file).
6. Repeat steps 4-5 for each <resource-ref> (and each <resource-env-ref>, if necessary).
resource-env-description

The resource-env-description element maps a <resource-env-ref> defined in ejb-jar.xml to the JNDI name of the actual resource. Typical examples of a <resource-env-ref> that is defined in the ejb-jar.xml file would be for administered objects, such as JMS destinations. You can find the actual JNDI name of those resources in the WebLogic config.xml file.

Using the <resource-env-description> element enables the client to bind the logical name for the resource to the actual JNDI name. The client looks up the resource using the logical JNDI reference (such as java:comp/env/<res-ref-name>) instead of the actual JNDI name (such as java:<jndi-name>), which isolates the client from changes to the JNDI name.

In WebLogic, the mapping of resources to JNDI names is specified in the weblogic-ejb-jar.xml file; 例如：
```
<resource-env-description>
        <res-env-ref-name>jms/Queue/RequestMailingMq</res-env-ref-name>
        <jndi-name>jms/Queue/RequestMailingMq</jndi-name>
</resource-env-description>
```
In WebSphere Application Server, the mapping of resources to JNDI names is specified using an assembly tool:
1. In Rational Application Developer, open the EJB project; for example: ShippingAutoserviceEJB .
2. Double click on the deployment descriptor.
3. Click on the References tab.
4. Expand the Java bean (for example, ShipmentManager ) to see all the JNDI resource references. You will need to specify a JNDI name for each reference. Select one of the references, such as jms/Queue/RequestMailingMq . As mentioned in the previous section, WebLogic treats the mapping of <resource-env-ref> to JNDI name differently than the mapping of <resource-ref> to JNDI name, but WebSphere Application Server treats their mappings the same. Thus, when you expand the correct Java bean you will see all <resource-ref> and <resource-env-ref> defined for that bean.
5. Scroll down to the WebSphere Bindings section and enter the JNDI name for that resource .
6. Repeat steps 4-5 for each of the <resource-env-ref> (and resource-ref> if necessary).

Mapping weblogic-cmp-rdbms-jar elements

This section describes how to map these elements from WebLogic to WebSphere Applicatioin Server:

See Related topics for more details on WebLogic configuration elements.

use-select-for-update

The use-select-for-update element enforces pessimistic concurrency on a per-bean basis. Specifying True causes the select for update extension to be used whenever the bean is loaded from the database and hold that lock for the duration of the transaction. Using this WebLogic extension makes it impossible for another transaction to read or update data while the first transaction is running. This extension increases data integrity and reduces deadlocks at the cost of reduced concurrency by holding locks for longer periods of time.

To find the EJBs that use select for update extension, search the weblogic-cmp-rdbms-jar.xml files for this element, noting the EJB project and the EJB name where it is used:

<use-select-for-update>

To map the <use-select-for-update> element to WebSphere Application Server:
1. In Rational Application Developer, open the EJB project.
2. Double click on the deployment descriptor.
3. Select the Access tab.
4. In the Access Intent for Entities 2.x (Bean Level) section, select the Java beans and press the Add button.
5. For Access Intent name, select wsPessimisticUpdate and press the Finish button.
If you set access intent to wsPessimisticUpdate, then the container will always use select for update, which may cause a performance problem, but will eliminate deadlocks. Therefore, leave the default access intent policies until you are able to run the load test to determine whether or not there are data integrity, deadlock, or performance problems. If so, then follow the above steps to set the access intent.
enable-batch-operations

The enable-batch-operations element controls whether or not the EJB container enables batch database operations, including batch inserts, batch updates, and batch deletes. If so, the EJB container delays database operations until transaction commit time.

By default WebLogic enables batch operations on entity beans unless it is explicitly turned off, which you can do by disabling the order-database-operations and enable-batch-operations elements (see the next section). To find these extensions search weblogic-cmp-rdbms-jar.xml file for this element:

<enable-batch-operations>false</enable-batch-operations>

Again, batch operations are enabled by default in WebLogic and can be disabled at the JAR level for all CMP entity beans inside the JAR. Batch operations are disabled by default in WebSphere Application Server, and can be enabled at the EJB container level for all CMPs in the container.

Since this is an all or nothing extension, you need to decide whether or not to enable batch operations for all CMP entities. You can start with the defaults (no batch operations enabled) and change if there are performance problems that you feel can be resolved with batch operations.

To enable batch operations in WebSphere Application Server:
1. From the admin console, navigate to Application servers => server_name => Process Definition => Java Virtual Machine .
2. After all the existing JVM arguments, add this argument to the Generic JVM arguments box:
  -Dcom.ibm.ws.pm.batch=true
Once again, the tradeoff is that batch database operations do not necessarily process updates in the same order as the code, but they do generally result in better performance. Therefore, consider starting without batching database operations (the WebSphere Application Server default) and turn it on if better performance is required.
order-database-operations

The order-database-operations element defers all database operations until the end of the transaction, automatically sorts the dependency between the operations, and sends these operations to the database in such a way as to avoid database constraint errors. In WebLogic, this element is enabled by default so you must explicitly disable it if you don't want to order database operations.

To disable order-database-operations, you must disable this element and the enable-batch-operations element (see previous section). If you do not disable both, the container will continue to order database operations.

In WebSphere Application Server, the ordering (and batching) of database operations is disabled by default and so you must explicitly enable it. To do so, you must enable deferred insert on create with these system parameters:

-Dcom.ibm.ws.pm.deferredcreate=true -Dcom.ibm.ws.pm.batch=true

The first parameter will defer the database insert until transaction commit time; the second one will defer all other operations being sent to the database until the transaction commits. If referential integrity violations are discovered during the load test, then you might also need to set the sequence grouping for container managed persistence.

To illustrate the need for maintaining referential integrity via the order database operations extension, consider an example:
1. Assume that entity bean Cust-A is related to Sales-A.
2. Assume further that Sales-A is deleted and Cust-A is assigned a new Sales-B.
3. If Cust-A has an integrity constraint instructing that it must have a sales person, then Cust-A must first be updated to the new Sales-B before Sales-A is deleted.
To set the sequence groups in WebSphere Application Server:
1. In Rational Application Developer, open the EJB project.
2. Double click on the deployment descriptor.
3. Click the Overview tab.
4. In the EJB CMP sequence groups section, click Add to launch the EJB CMP Sequence Group wizard.
5. Type a name for your sequence group.
6. Type your group type designation in all uppercase characters: RI_INSERT or UPDATE_LOCK . In the case of delete operations, the persistence manager reverses the order in the RI_INSERT group and deletes the beans and their corresponding database rows accordingly.
7. In the Available Beans list, highlight the first bean that you want to place in the group. Click the arrow pointing toward the Selected beans list to move it from the Available beans list and to the Selected beans list.
8. Repeat step 7 until you have added all beans in the sequence you want the persistence manager to handle them.
weblogic-ql

The weblogic-ql element specifies a query that contains a WebLogic-specific extension to the EJB 2.0 Query Language (EJB-QL). Standard EJB-QL language features are used in the ejb-jar.xml deployment descriptor, and WebLogic EJB-QL extensions are used in the weblogic-cmp-rdbms-jar.xml. Ordering, aggregate functions, and subqueries are usually used in queries, but since other extensions could be used as well, always carefully inspect all weblogic-ql elements.

WebSphere Application Server also extends the EJB-QL language features, but instead of defining a separate QL, WebSphere Application Server provides ordering, subqueries, and aggregate functions to the EJB-QL syntax . That is, WebSphere extends the syntax of EJB-QL to include these extensions. Therefore, you can use EJB-QL plus its extensions in the standard ejb-ql element in the ejb-jar.xml file.

To map the weblogic-ql element to the ejb-ql element:
1. In Rational Application Developer, open the EJB Project.
2. Double click on the Deployment Descriptor.
3. Click on the appropriate Java bean.
4. Scroll down to the Queries section.
5. Select the appropriate query and press the Edit button to display the Edit Finder Method dialog.
6. Follow the wizard steps to construct the correct query statement.
The next sections show the mapping of query statements from weblogic-ql element to ejb-ql element.

Mapping orderby

The orderby WebLogic QL extension is a keyword that works with the Finder method to specify the order of the results returned from your selections. You can also order by multiple fields and specify whether to return the results in ascending or descending order.
- Sample weblogic-ql element:
  
  <weblogic-ql>select object(o) from MeetingAutoservice o where o.idInternAutoservice = ?1 orderby o.numberMeeting</weblogic-ql>
- Mapped ejb-ql element:
  
  <ejb-ql>select object(o) from MeetingAutoservice o where o.idInternAutoservice = ?1 order by o.numberMeeting</ejb-ql>
Mapping subquery and aggregate functions

The subquery WebLogic QL extension enables a query to be embedded within the WHERE clause of the main query to return data for use in the main query as a condition to further restrict the data to be retrieved. The MAX WebLogic QL extension returns the maximum value of the specified field. This example shows a subquery and aggregate function and its mapping to WebSphere Application Server:
- Sample weblogic-ql element:
  
  <weblogic-ql>select OBJECT(o) from MeetingAutoservice o where o.idInternAutoservice=?1 AND o.meetingNumber = (select MAX(p.meetingNumber) from MeetingAutoservice p where p.idInternAutoservice = ?1)</weblogic-ql>
- Mapped ejb-ql element:
  
  <ejb-ql>select OBJECT(o) from MeetingAutoservice o where o.idInternAutoservice=?1 AND o.meetingNumber = (select MAX(p.meetingNumber) from MeetingAutoservice p where p.idInternAutoservice = ?1)</ejb-ql>
max-elements

The max-elements element specifies the maximum number of elements that should be returned by a multi-finder or ejbSelect method. That is, it limits the number of rows returned in a query similar to the maxRows feature in JDBC.

According to the J2EE specification, if you don't limit the size of the result set, then when a multi-object finder or ejbSelect method is executed, the ResultSet is read to the end and the client receives the entire collection through which to iterate. Clearly, this approach is not efficient for big resultsets (collections).

To find all the occurrences of max-elements, search the weblogic-cmp-rdbms-jar.xml for this element:

<max-elements>

With WebSphere Application Server, you cannot limit the number of rows that are fetched from a finder. If an application is using max-elements, you will need to modify the code; one possible modification is to write appropriate logic in a facade to FETCH FIRST n ROWS from the result set.

That said, in general, it is a good programming guideline to say that any finder with a result set of more than 10 should be implemented with JDBC to avoid the relatively memory intensive EJB finder methods, because finders that return more than ten elements could be problematic if the application is intended to be high volume.

结论

This article described how to find WebLogic proprietary extensions in an application and how to migrate those proprietary extensions to WebSphere Application Server -- but just because you find them doesn't mean you should implement them all. In general, when migrating an application from WebLogic to WebSphere Application Server:

Carefully review all of the WebLogic proprietary settings so that you know in advance which extensions have been applied to the application. This will help you better test and tune the application, estimate how long the migration will take, and help you avoid surprises.
Implement those extensions -- and only those extensions -- that are required to get the application to run. Required extensions would be those that create the managed resources (JDBC connection pool, JMS connection factories, and so on) that are required by the application.
Once the application is running, implement those extensions as required to meet the performance and scalability requirements of the application. That is, start with the default WebSphere Application Server settings and then let the load test guide you in terms of which other extensions might need to be implemented.
Resist the urge to re-factor that application -- at least until the migration is complete. For instance, if the application uses pessimistic locking, don't change the application during the migration to use optimistic locking. Test and tune the application to get it running as best it can, then consider re-factorings later.

Knowing how to identify and migrate WebLogic extensions to WebSphere Application Server and following these guidelines will help will help you achieve a successful migration while eliminating many surprises along the way.

翻译自: https://www.ibm.com/developerworks/websphere/library/techarticles/0706_vines/0706_vines.html

cuxiong8996

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

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

迁移服务器配置

图1.服务器配置迁移

迁移应用程序配置

图2.行业标准部署描述符

图3.特定于供应商的部署描述符

映射config.xml元素

映射WebLogic启动脚本

映射weblogic-ejb-jar元素

Mapping weblogic-cmp-rdbms-jar elements

结论