Preparing Your Database

Preparing your database for WebLogic Integration requires the use of WebLogic Platform tools and the application of best practices for your RDBMS. For requirements and recommendations that are general to the WebLogic Platform, see Managing WebLogic Platform Database Resources.

For more information specific to WebLogic Integration, see the following topics:

• Configuring Your Database

• Related Topics

Configuring Your Database

WebLogic Integration solutions can be configured for single-server or cluster environments. To configure your database resources:

 For a single-server environment...

Use the Configuration Wizard as described in Configuring a Single-Server Deployment in Deploying WebLogic Integration Solutions.

 For a cluster environment...

Use the Configuration Wizard as described in Configuring a Clustered Deployment in Deploying WebLogic Integration Solutions.

 For a production environment...

Use the SQL scripts described in Configuring a Production Database in Managing WebLogic Integration Solutions.

If your configuration includes DB2:

• Tune the size of the DB2 output buffer to accommodate Trading Partner Management transaction activity. If the output buffer is too small, an asynchronous service queue will throw an exception.

If your configuration includes Sybase:

• Increase the Sybase procedure cache from the default of 3271 to a size that will enable messages of a size typical in your WebLogic Integration application to be exchanged. The procedure cache percent should be set to 25%. This number specifies the percent of memory allocated to the procedure cache after allocating the memory Sybase Server needs for locks, user connections, and the server code itself. If messages exceed the size of the procedure cache, the message may fail with a BEA-463014 exception.

• Create a large transaction log segment and a threshold process that sends notification to the database administrator when the log segments fills to a certain percentage of its size. The database administrator should manually dump the log to prevent it filling up under load.

If your configuration includes Oracle:

• When you create the tables for a WebLogic Workshop web service being deployed to a production environment, you should store BLOB and CLOB data in one or more tablespaces that do not contain other types of data.

  The following WebLogic Integration system tables have BLOB or CLOB columns:

  • WLI_CALENDAR
  • WLI_PROCESS_DOCUMENT
  • WLI_PROCESS_EVENT
  • WLI_PROCESS_TRACKING
  • WLI_WORKLIST_DATA
  • WLI_MT_CONTENT

  The following archive tables include BLOB or CLOB columns:

  • WLI_DOCUMENT_DATA
  • WLI_TASK_ARCHIVING
  • WLI_TASK_DATA_ARCHIVING

  The BLOB and CLOB data for all of these tables should be segregated from other data and should not be stored in the USERS tablespace. Storing BLOB or CLOB data in the USERS tablespace can exhaust the tablespace's storage capacity.

  You can use the following table creation scripts as a template for creating conversation tables with a new tablespace for the BLOB data:

     CREATE TABLE <*tableName*>(
     CG_ID varchar(768) not null,
     LAST_ACCESS_TIME number(19,0),
     CG_DATA BLOB,
     PRIMARY KEY (CG_ID)
     )
     LOB("CG_DATA") STORE AS ( TABLESPACE <*blobTablespace*> )
  

• The entity bean Exclusive concurrency strategy should be used to minimize Oracle lock conflicts in a cluster environment. (Entity beans in environments using other types of databases should be configured to use the Database concurrency strategy.) Exclusive is the default concurrency strategy. For more information about setting concurrency strategies, see wlw-config.xml Configuration File in WebLogic Workshop Help.

• Tune your database connection processes and set the WebLogic execution process Threadcount to a number appropriate for your application load. If there are too few connection processes available to handle concurrent messages being sent to the database, ORA-27101 exceptions occur. For information about configuring WebLogic execution thread pools, see Creating Execute Queues in the WebLogic Server Performance and Tuning. Contact your Oracle DBA for assistance in tuning your database connection processes.

• When trading partners engage in conversations involving large numbers of messages exchanged and persisted in runtime as well as archive tables, the cursors available in Oracle databases may be insufficient and exceptions similar to the following may be thrown:

  java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1 ORA-0100: maximum open cursors exceeded

  To avoid this situation, you can set the statement cache size for each JDBC connection pool to zero. To configure the statement cache, follow these steps:

  1. Launch the WebLogic Server Administration Console.
  2. In the left pane, click to expand the Services, JDBC, and Connection Pool nodes to display the list of connection pools in the current domain.
  3. Click the connection pool that you want to configure. The right pane displays tabs associated with this instance.
  4. Click the Configuration tab, and then click the Connections tab.
  5. In Statement Cache Size, enter 0 (zero) as the number of statements to cache per connection pool instance.
  6. Click Apply to save your changes.
  7. Repeat Step 3 through 6 for each connection pool.

  For more information about statement cache size, see "Tuning Connection Pools" in JDBC Connection Pools in the WebLogic Administration Console Online Help.

• The Trading Partner Management repository implements the NOTES field in its database tables as a LONG data type and the WLI_TPM_XML_ELEMENT as a TEXT data type on Oracle databases. The use of these data types may obstruct certain database management functions:

  • Utilities such as import and export require that each row fits in memory, including the full length of any LONG value. Since LONG values can be up to 2 GB in length, this may effectively prevent import and export from working.
  • The move utility cannot be used on tables that contain LONG fields.
  • There is no way to segregate LONG data into their own tablespace.
  • Tables with LONG columns cannot be replicated using Oracle's replication services.
  • Tables with LONG columns cannot be partitioned.

If your configuration includes Pointbase:

• When you use the Configuration Wizard in Custom mode and specify Pointbase ports other than the default (9093), you must edit the startWebLogic script (startWebLogic.cmd for Windows) and add the -port=XXXX option (where XXXX represents the correct port value) in the line that starts the startPointBase scripts after the startPointBase command.

• If the size of the data stored in process variables will exceed 4 MB, manually create or modify the conversation state tables in the database so that the column size is larger than the size of the data stored in process variables. During development, these tables are typically autocreated by WebLogic Workshop with names based on the application, package, and filename of the source (for example, JWS_WLIPROD_BPM_ORDERPROCESSOR). If the data stored in a process variable exceeds the size of the conversation state table column size, all conversations are terminated in the current process.

Related Topics

System Configuration in Managing WebLogic Integration Solutions

Learn how to manage the WebLogic Integration datastore.

Using the Trading Partner Bulk Loader in Managing WebLogic Integration Solutions

Learn how to import, export, and delete Trading Partner Management data.