WebSphere migrations: Migrating WebLogic server and application configurations to WebSphere Application Server

Learn to migrate WebLogic application and server configurations to IBM® WebSphere® Application Server with this article, which identifies those WebLogic proprietary extensions that must be properly mapped for your applications to run on WebSphere Application Server. Solutions to common problems are included so you can navigate your migration with minimum difficulty.

Share:

Donald Vines (dhvines@us.ibm.com), Executive IT Architect, IBM

Donald Vines is currently an Executive IT Architect at IBM responsible for the WebSphere migration practice within North America.


developerWorks Contributing author
        level

06 June 2007

Also available in Chinese Japanese

Introduction

The objective of this article is to help you migrate Java™ 2 Platform, Enterprise Edition (J2EE) applications from BEA WebLogic Server to the IBM WebSphere Application Server platform.

Other developerWorks articles (see Resources) discuss the planning of a WebLogic migration, including migrating the development environment, production runtimes, application code, and so on. This article complements those and other resources by focusing specifically on migrating the two types of configurations that exist in a J2EE application:

  • Server configuration refers to the settings contained outside the application files but within the domain configuration of the source environment. To migrate the server configuration, WebLogic-specific resources, such as JMS connection factories, JMS queues, JMS topics, JDBC data sources, JavaMail sessions, and so forth, are mapped to their WebSphere Application Server equivalents.

  • Application configuration refers to those settings that are self-contained within the application directory structure of the enterprise archive (EAR) file. To migrate the application configuration, WebLogic-specific deployment descriptors are mapped to their WebSphere Application Server equivalents.

The issues discussed in this article apply directly to the migration of J2EE 1.3 (and greater) applications from WebLogic Server 7.0 and 8.1 to WebSphere Application Server V6.x. Most of the information here also applies to the migration applications from earlier versions of WebLogic Server as well.


Migrating the server configuration

Migrating the server configuration essentially means moving the settings that are contained outside the application files -- but within the domain configuration -- of the WebLogic Server to WebSphere Application Server. These settings can include JMS connection factories and destinations, JDBC data sources, J2EE security settings, mail sessions, and so on.

To migrate the configuration, you must know what settings need to be migrated. However, it is quite possible that you won't have any documentation about these settings, nor any scripts (that might have been used to create the server configuration) for reference. If that is the case, you will need to log into the WebLogic administrative console in each domain to find the settings so you can determine which ones you need to create in the WebSphere Application Server environment.

But what if you are unable (or not permitted) to access to the WebLogic admin console?

Either way, the most efficient way to gather the WebLogic server configuration information is to inspect the WebLogic domain configuration file, config.xml, and the WebLogic startup script. WebLogic administrators will typically provide you with a copy of these files, since reviewing them will not impact any running systems.

  • The WebLogic config.xml file is where the WebLogic admin console stores all resource definitions. Failure to map these resources properly will likely cause an application to fail.

  • Administrators often create a custom startup script and then add system properties, JVM arguments, and classes to it. Failure to migrate these settings could adversely impact the performance and scalability of an application in the new environment. It is a good idea to review the startup script, regardless of whether you look at the config.xml file or the admin console.

After you have gathered this information, be sure to ask the developers and administrators to review what you have collected. This is to:

  • Verify that the information you gathered contain the most current and accurate settings.
  • Identify any dead code that can be removed.

Also, make sure that you are looking at the correct WebLogic server configuration; during development, a J2EE application can be installed in many different run time environments (development, test, QA, and so on), each of which can have slightly different configuration settings. Therefore, be sure the WebLogic server configuration you use is the right one for your purposes. Similarly, as you install the application at each development stage, make sure that you map the proper server configuration for each corresponding environment.

With the specific run time configuration settings that need to be migrated in hand, your next step is to extract them and plug the information into the WebSphere Application Server administrative console. Although this is a manual process, it is not difficult to create the settings once you know which ones need to be created. Using the WebSphere Application Server admin console to set these properties isolates you from having to modify XML files or write scripts. If you prefer, there are also guided activities to help you perform common tasks, such as creating a data source, enabling J2EE application security, and so on. Once completed, you can write scripts to automate the creation of the server configuration, particularly for the production environment.

Figure 1 illustrates the server migration from WebLogic to WebSphere Application Server. The settings shown are not the only server configuration settings, but they cover most of what you see during such a migration. Other settings you find might be related to security and mail sessions, but, in general, if you can handle the resources shown in the figure, you are well on your way to a successful server migration.

Figure 1. Server configuration migration
Figure 1. Server configuration migration

Migrating the application configuration

Migrating the application configuration essentially means moving the settings that are contained in the WebLogic-specific deployment descriptors to WebSphere Application Server. These settings include mapping of EJB components to the global JNDI namespace, and various performance-related settings, such as the pool size, isolation levels for transactions, extensions to the EBJ query language, and so on. Deployment descriptors describe the required execution environment for a J2EE application and have in two general variations:

This article does not address deployment descriptors for Web services, the mapping of which will be covered in a follow-on article.

  • Industry standard deployment descriptors (Figure 2) are portable and don't generally require any changes, but there are some differences between WebLogic and WebSphere Application Server that are worth noting. For instance, IBM's standard deployment descriptors use IDs to correlate information in the standard descriptor with information in the vendor-specific descriptors, whereas WebLogic uses ejb-names for its correlation instead. Thus, when you migrate the WebLogic deployment descriptors and create the IBM-specific descriptors, you will need to add the appropriate IDs to them. Let your assembly tool, such as IBM Rational® Application Developer, create these IDs for you; if you try to create these IDs yourself and get it wrong, there will be difficult errors to resolve.

    Figure 2. Industry standard deployment descriptors
    Figure 2. Industry standard deployment descriptors
  • Vendor-specific deployment descriptors (Figure 3) must be migrated. Figure 3 shows the WebLogic-specific deployment descriptors and the corresponding WebSphere-specific deployment descriptors.

    Figure 3. Vendor-specific deployment descriptors
    Figure 3. Vendor-specific deployment descriptors

    IBM provides a number of tools to help you migrate the WebLogic deployment descriptors to WebSphere Application Server, including:

    • Xdoclet tags
    • WebSphere Rapid Deployment tags
    • Application Server Toolkit (deployment descriptor editor)
    • IBM J2EE Competitive Migrator Plug-in for Rational Application Developer V6.

    See Migrating Applications from WebLogic, JBoss and Tomcat to WebSphere V6 to learn what these tools do, how and when to use them, where to get help, and more. It is important to know about these tools and to use them when appropriate. While these tools will map some of the extensions in vendor-specific deployment descriptors, they will not map all of them, so it will still be important for you to inspect the deployment descriptors and know how to map the extensions that you find in them. With this understanding, using an assembly tool like the Application Server Toolkit can be quite effective.


Mapping config.xml elements

This section describes how to map these server configuration elements from WebLogic to WebSphere Application Server:

  1. JMSConnectionFactory
  2. JMSFileStore
  3. JMSServer
  4. ForeignJMSServer
  5. JDBCConnectionPool and JDBCDataSource

See WebLogic Server Configuration Reference for more details on each element.

  1. JMSConnectionFactory

    The JMSConnectionFactory element creates a connection factory object and binds it into the JNDI namespace. There are three connection factories configured in config.xml file for this application; each of which has enabled 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"
    />

    To map this configuration to WebSphere Application Server, you generally want to create the JMS connection factories shown above in the WebSphere default messaging provider. Some additional precautions include:

    • Use the correct JNDIName when you configure these JMS connection factories inside WebSphere Application Server. If the JNDI names are not right, then the application will not be able to locate the connection factories.

    • Verify whether or not the message-driven beans (MDB) are transactional because there may be some performance gain by disabling XA for non-transactional MDBs that specify a transaction attribute of "NotSupported." Non-transactional MDBs cannot participate in an XA transaction and don't require an XA-enabled connection factory. On the other hand, if the MDB specifies a transaction attribute of "Required," then XA should be enabled for its connection-factory-jndi-name.

    • XA is enabled by default when you create the connection factory in WebSphere Application Server.

  2. JMSFileStore

    The JMSFileStore element defines a disk-based JMS file store that stores persistent messages (for queues) and durable subscribers (for topics) in a file system directory. This code fragment shows the definition of a single JMS file store:

    <JMSFileStore 
          Directory="/log//weblogic/wl-myserver/rmfilestore"
          Name="FileStoreMailing" SynchronousWritePolicy="Cache-Flush"
    />

    To map this configuration to WebSphere Application Server, you first need to know that WebSphere Application Server V6.0 default messaging does not support a JMS file store. The file store is an enhancement in Version 6.1, but if you're using Version 6.0, you will need to define a JDBC data source for the messaging engine.

  3. JMSServer

    The JMSServer element defines a JMS server that manages connections and messages to its JMS destinations (referring to the JMSQueue or JMSTopic elements). This code fragment from the config.xml file shows three JMS servers, each of which contains two JMS destinations, here using JMS queues:

    <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>

    In this WebLogic configuration, only one of the JMS servers (JMSServerMailing) uses the file store. The other two do not specify a JMS store at all, so the queues in those JMS servers do not support persistent messages.

    Unless the application explicitly sets the delivery mode (PERSISTENT or NON_PERSISTENT) for a destination, the WebLogic config.xml file will specify whether or not messages are persistent. Therefore, those JMS servers that have a non-null file store will use persistent delivery mode to their destinations, while those JMS servers that do not have a file store will use a non-persistent delivery mode.

    To map this configuration to WebSphere Application Server, use persistent messaging for the two destinations that are defined in the JMSServerMailing JMS server, and non-persistent delivery mode for all of the other destinations. Once again, be sure to use the correct JNDIName when you configure these JMS queues inside WebSphere Application Server. If the JNDI names are not right, then the client application will not be able to locate the JMS destinations.

  4. ForeignJMSServer

    The ForeignJMSServer element defines a JNDI provider that is outside the WebLogic JMS server and is the parent element of the ForeignJMSConnectionFactory and ForeignJMSDestination elements. Together, these elements provide information that enables WebLogic Server to reach the remote JNDI provider so that clients can use local JNDI names to refer to the remote connection factory and destination objects. You will often see this when using WebSphere MQ as the JMS provider. This code fragment from the config.xml file shows one foreign JMS server, one foreign JMS connection factory, and two foreign JMS destinations:

    <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>

    The foreign JMS servers, connection factories, and destinations in this configuration will be mapped to the WebSphere MQ JMS provider. It is important that you correctly configure the LocalJNDINames and RemoteJNDINames.

  5. JDBCConnectionPool and JDBCDataSource

    The JDBCConnectionPool and JDBCTxDataSource elements define the configuration of a JDBC resource. This code fragment from the config.xml file shows the configuration of a single connection pool and data source:

    <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"/>

    In this code:

    • The JDBCConnectionPool element defines the properties connections that are returned from the pool when getConnection is called on the data source.

    • The JDBCTxDataSource element defines a transaction-enabled JDBC data source, and specifies the JNDI name where the data source is bound and the connection pool that is associated with this data source.

    To map the connection pool and data source to WebSphere Application Server, configure a JDBC provider, JDBC data source, and JCA authentication data entry. The most important elements are JNDIName, DriverName, URL, PasswordEncrypted, and Properties. (You will need to get the password from the database administrator, as it is encrypted in the config.xml file.)

    To map the TestTableName attribute, use the WebSphere property called PreTest SQL string, where you can set an SQL sentence to test each JDBC connection. You can also set the connection retry interval.

    You should also configure pool size based on the <InitialCapacity> and <MaxCapacity> elements. By default, the WebSphere Application Server connection pool will have a minimum of one connection and a maximum of ten connections. The WebLogic connection pool is configured to start off with 25 connections, so you will want to configure the WebSphere pool size. To do that:

    1. Open the WebSphere Application Server admin console and select Resources => JDBC Providers.
    2. Select the name of the provider.
    3. Select the Data Sources entry under Additional Properties.
    4. Click on the data source name.
    5. Select Connection pool properties.
    6. Use the minimum and maximum connection fields to configure the pool size.

There are several other WebLogic-specific attributes that can be used to configure a JDBC resource, but those listed above are most frequently encountered.


Mapping the WebLogic startup script

This section describes how to map these server configuration elements from WebLogic to WebSphere Application Server:

  1. JVM arguments
  2. System arguments
  3. Classpath

See Resources for more information on WebLogic configuration elements.

  1. JVM arguments

    It is a common WebLogic practice to specify the JVM arguments in a custom startup script. Be sure you acquire the correct startup script for the correct environment. Here is an example showing Sun™ JVM options being used:

    -server -Xms1024m -Xmx1024m 
    -verbose:gc -Xloggc:wls-gc.log  -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 
    -XX:ParallelGCThreads=8 -XX:PermSize=128m -XX:MaxPermSize=128m

    Assuming that you will be running WebSphere Application Server on the same JVM that was tuned for WebLogic, the above extensions should be a good starting point in tuning the JVM for WebSphere Application Server, but you may want to adjust them based on the load test. To add these JVM arguments to WebSphere Application Server:

    1. From the amin console, select Servers => Application Servers -=> server_name => Process Definition => Java Virtual Machine.
    2. Check Verbose Garbage Collection (remember to turn it off).
    3. Set the Initial Heap Size to 1024.
    4. Set the Maximum Heap Size to 1024.
    5. Add -server as the first argument in the Generic JVM arguments box then add the following arguments after the other existing arguments:
      -XX:ParallelGCThreads=8 
      -XX:PermSize=128m 
      -XX:MaxPermSize=128m
      -Xloggc:wls-gc.log  
      -XX:+PrintGCDetails 
      -XX:+PrintGCTimeStamps

    Some things to keep in mind:

    • Verbose garbage collection is enabled by way of the -verbose:gc option. It's great to gather garbage collection statistics during the load test, but every major and minor collection will be logged, so remember to disable verbose garbage collection before the final benchmark is run.

    • Class garbage collection is enabled by default, which removes classes when they don't have any live instances remaining. Class garbage collection has lead to performance and scalability problems in other WebLogic migrations, so disable it by adding this JVM argument:

      -Xnoclassgc

    For additional information on tuning the Sun and other JVMs, see Tuning Java virtual machines.

  2. System arguments

    All of the -D arguments that are specified in the WebLogic startup script should be mapped to WebSphere Application Server. Failure to map the system arguments will most certainly result in migration problems. To map the system arguments to WebSphere Application Server:

    1. From the admin console, select Application servers => server_name => Process Definition => Java Virtual Machine.
    2. In this example, the startup script has one argument that enables caching and another argument that specifies the location of the log4j configuration file. You should add these arguments to the Generic JVM arguments box after all existing JVM arguments:
      -Dtangosol.coherence.distributed.localstorage=true 
      -Dlog4j.configuration=file:///myprojects/config/log4j.xml
  3. Classpath

    You will often find that the WebLogic classpath has been modified in the startup script. This may have been done to add JARs that are either not contained in the application's enterprise archive, or that are used to add directories to be searched for configuration files that are loaded by the application. To map them in either situation:

    1. From the admin console, select Application servers => server_name => Process Definition => Java Virtual Machine.
    2. In this example, the WebLogic startup script added a directory to the classpath, and so you add it to WebSphere Application Server classpath as well. Add thsi folder to the Classpath box:

      C:\myprojects

      Be careful about adding JARs to the classpath, and do so only if you are sure they are not already included in the WebSphere Application Server distribution.


Mapping weblogic-ejb-jar elements

This section describes how to map these server configuration elements from WebLogic to WebSphere Application Server:

  1. jndi-name
  2. local-jndi-name
  3. max-beans-in-free-pool and initial-beans-in-free-pool
  4. max-beans-in-cache and idle-timeout-seconds
  5. trans-timeout-seconds
  6. concurrency-strategy
  7. enable-call-by-reference
  8. cache-between-transactions
  9. delay-updates-until-end-of-tx
  10. finders-load-bean
  11. resource-description
  12. resource-env-description

See Resources for more information on WebLogic configuration elements.

  1. jndi-name

    The jndi-name element specifies the JNDI name of the EJB in the global JNDI namespace. To set the EJB's JNDI name in WebSphere Application Server, you need to know the EJB project and the correct EJB. To find them, search the weblogic-ejb-jar files for this element:

    <jndi-name>

    To map the jndi-name elements to WebSphere Application Server:

    1. Start your assembly tool and open the EJB project.
    2. If you are using Rational Application Developer, double-click on the deployment descriptor.
    3. Click on the appropriate EJB component.
    4. Scroll down to the WebSphere Bindings section and enter the JNDI name for that bean.
  2. local-jndi-name

    The local-jndi-name element defines the JNDI name for the bean's local home in the global JNDI namespace. That is, WebLogic provides a way to specify the JNDI name for the local homes in the global JNDI namespace -- but doing so enables remote clients to lookup local interfaces in the global JNDI namespace, which can result in run time errors, since local homes must be collocated in the same container as the client. Now, before looking at the WebSphere side, consider the background of JNDI:

    • The J2EE specification does not specify the mapping of EJBs into the global JNDI namespace. That is left up to the vendor. Therefore, most vendors include an element in their own specific deployment to specify the remote EJB JNDI name in the global JNDI namespace.

    • However, by definition, local home interfaces can only be accessed by the local container, so vendors do not need to bind them to the global JNDI namespace. While the client module might lookup local homes using JNDI, the container need not expose them in the JNDI namespace. Instead, client modules should define a JNDI reference to the EJB and access it in the local namespace using java:comp/env as part of the lookup.

    • The industry recommends that you use JNDI references to access EJBs in the local namespace rather than use JNDI names to access EJBs directly in the global namespace. Using JNDI references isolates the client module from changes to the global JNDI namespace, which is required to support multiple versions of the same EJB. That is, client modules using the same JNDI reference can be bound to a new version of the EJB without having to modify any source code; the client module just binds their JNDI reference to point to a different EJB.

    Now, given this background, how do you map the local-jndi-name element to WebSphere Application Server?

    First, you need to understand that WebSphere Application Server does not provide a way to define the JNDI name for a local home. Instead, you must access local beans using a JNDI reference in the local namespace -- not the JNDI name in the global namespace.

    Unfortunately, some WebLogic applications reference local objects directly in the global JNDI namespace using JNDI name, rather than reference them indirectly using a JNDI reference in the local JNDI namespace. Thus, some code changes will be required to those applications. There are a few ways you can map the local-jndi-name element to WebSphere Application Server that are either unsupported or impractical. But one method you can use is to add local JNDI references to caller modules -- which is the standard way to lookup local homes -- and then use the java:comp/env prefix in all JNDI lookups. This is the industry-recognized best practice for accessing not only EJBs but also other resources (like JMS connection factories), so it is the solution you should use here.

  3. max-beans-in-free-pool and initial-beans-in-free-pool

    The max-beans-in-free-pool element defines the maximum size of the free pool of EJBs for a specific entity bean, stateless session bean, or message-driven bean. Each bean class can define the size of its own free pool using this element.

    The initial-beans-in-free-pool element defines the initial number of bean instances that will populate the free pool for a specific bean class at startup. Populating the free pool with instances improves initial response time, because initial requests for the bean can be satisfied without generating a new instance.

    In WebLogic, each and every bean in the application can specify its maximum and initial pool size and the pool sizes can vary significantly from one bean class to the next. To determine the specific pool sizes, look at the weblogic-ejb-jar.xml file for one of these elements:

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

    To specify the EJB pool sizes in WebSphere Application Server, you can add a system argument to the JVM:

    1. From the admin console, select Application servers => server name => Process Definition => Java Virtual Machine.
    2. Add com.ibm.websphere.ejbcontainer.poolSize to the Generic JVM arguments box after all the existing JVM arguments. Here is an example that sets the pool size minimum to 1 and maximum to 5 for a bean called RuleEngineEJB:
      -Dcom.ibm.websphere.ejbcontainer.poolSize
      =myapp#RulesEngine.jar#example.RulesEngineEJB=1,5

    See WebSphere EJB Container Tuning for additional details.

    Although you can map the pool size extensions, the application servers treat the free pool differently:

    • WebLogic will not create another instance if the pool is empty; the request for the new bean will have to wait until an existing bean is returned to the pool. This policy could lead to deadlock situations if the pools are not sized correctly, but it controls the number of active objects, which might help scalability.
    • WebSphere Application Server will create a new instance if the pool is empty (instead of making that request wait). After the request uses that new instance, WebSphere Application Server will only return it to the pool if there are not already maxSize beans in the pool. (The default pool sizes in WebSphere Application Server are 50 minimum, 500 maximum.)

    It is important to note these differences because in certain situations they can lead to performance and scalability problems in WebSphere Application Server if the bean pools are being exhausted under heavy load, if it is expensive to create the object, or if it consumes too many resources. For instance, consider this situation:

    • An application implements a session bean that is very expensive to create. An example of such a session bean might be one that provides an interface to a rules engine that caches its rule base (which may be hundreds of megabytes of data) in the heap.

    • Since this bean is so expensive to create and since it consumes so much of the available space in the heap, the application limits the maximum number of beans in the free pool to 5, which actually limits the number of such beans to 5 at any given time.

    • The application limited the number of active beans because it is better (from a scalability point of view) to service all incoming requests for this "rules service" through 5 active session bean instances, instead of continually creating/destroying additional session beans under heavy load.

    Now, that you map this pool size with a minimum of 1 and a maximum of 5 to WebSphere Application Server. The mapping works fine, in that it does limit the pool size to 5, but it doesn't limit that number of active instances to 5. If there are five requests using all five of the session beans, then the pool will be empty, but if a sixth request comes in for one of those session beans, then a sixth session object will be created and used -- just not returned to the pool. In WebLogic, the request for a sixth session object would have to wait for one of the active beans to be returned to the pool before continuing.

    As you can see, this straight mapping of pool sizes can lead to additional session beans being created, and under heavy load this creation and destruction of additional beans can lead to scalability problems. If the application requires a hard limit on the number of active sessions, then the bean will need to keep track of the number of beans in the free pool and wait for an active bean to complete if there are none available.

    An important lesson to take from this example is that, during load testing, you will want to keep an eye on the maximum number of beans that are active to make sure they do not exceed the maxSize of the pool. If they do, then you might want to resize the pool larger to avoid continually creating and destroying objects; either that or you will want to implement a hard limit on the number of active beans.

  4. max-beans-in-cache and idle-timeout-seconds

    The max-beans-in-cache element controls the maximum number of objects of this class that can be active at any given time. When the value of max-bean-in-cache is reached, WebLogic passivates some EJBs that have not recently been used by a client.

    The idle-timeout-seconds element specifies the maximum amount of time a bean remains in the cache. When this time has elapsed, the container removes the bean if the number of beans in cache approaches the max-beans-in-cache. (This element was ignored prior to WebLogic 8.1 SP4.)

    In WebLogic, you can define the cache for individual bean classes. The objects that can be in memory can vary depending on the class, as can the idle timeout. To find the customized caches, search weblogic-ebj-jar.xml for one of these elements:

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

    With WebSphere Application Server, you cannot specify the cache size or the idle-timeout (called cleanup interval in WebSphere Application Server) per bean class, but you can specify the cache size and cleanup interval for the instances that can be active in the entire EJB container.

    The cache size in WebSphere Application Server is similar to the max-beans-in-cache. It specifies the number of buckets in the active instance list within the EJB container. Although a bucket can contain more than one instance, when the number of active instances exceeds the number of buckets (cache size), the container tires to remove some instances by passivating them to disk. Thus, performance is best if the cache size is set to the maximum number of active instances expected during a typical workload.

    The cleanup interval in WebSphere Application Server is similar to idle-timeout-seconds. It specifies the interval at which the container attempts to remove unused items from the cache in order to reduce the total number of items in the cache to the value of the cache size.

    If you encounter an application where there has been tuning of the WebLogic cache sizes on a class-by-class basis, you should consider those cache sizes in tuning the WebSphere EJB cache size. There's an algorithm you can use to tune the EJB cache size of the container that calculates the average EJB cache requirements based on the different kinds of beans.

    If there is a large number of entity beans in the application, you should calculate the expected maximum value of EJBs active in the container at any instance in time using the values of the max-beans-in-cache element and monitor the cache during the load test to verify that evictions are not occurring from the cache; that is, make sure there is not a high rate of ejbStores being called. This action is important because the default maximum cache size in WebSphere Application Server is only a few thousand, and applications with heavy use of entity beans may already specify pool sizes of several thousand.

  5. trans-timeout-seconds

    The trans-timeout-seconds element specifies the maximum duration for an EJB's container-initiated transactions. If a transaction lasts longer than trans-timeout-seconds, the WebLogic EJB container will roll back the transaction. You can see this extension by searching all the weblogic-ejb-jar.xml files for this element:

    <trans-timeout-seconds>

    WebSphere Application Server offers two ways to set the transaction timeout.

    Option 1: If all of the beans set the transaction timeout to the same value, then you can set the maximum transaction timeout in the WebSphere transaction service using the admin console:

    1. From the admin console, select Servers => Application servers => server_name => Container Services => Transaction Service.
    2. Set Total transaction lifetime timeout to 30.

    Option 2: You can set the transaction timeout in the deployment descriptor for the beans. To do that:

    1. In Rational Application Developer, for each EJB project, double click on its deployment descriptor.
    2. Double click on the specific bean to set the transaction timeout.
    3. Set the Component transaction timeout integer to 30.

    The general recommendation is to change the deployment descriptor of the bean rather than the transaction service for all beans. Changing the transaction timeout for all beans will impact all applications running in that container. 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.

  6. 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 Resources 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. This is the default option.

      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.
  7. 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.
  8. 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.

  9. 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.

  10. 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.

  11. 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; for example:

    <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).
  12. 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; for example:

    <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:

  1. use-select-for-update
  2. enable-batch-operations
  3. order-database-operations
  4. weblogic-ql
  5. max-elements

See Resources for more details on WebLogic configuration elements.

  1. 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.

  2. 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.

  3. 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.
  4. 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>

  5. 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.


Conclusion

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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=227092
ArticleTitle=WebSphere migrations: Migrating WebLogic server and application configurations to WebSphere Application Server
publish-date=06062007