Creating WebLogic Domains Using the Configuration Wizard

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Customizing JDBC and JMS Settings in WebLogic Domains

When you are creating or extending a domain using the Configuration Wizard, you can change JDBC data source and JMS file store settings if they are defined in the domain or template that you selected as the source for domain that you are creating.

Note: If you select Yes in the Customize Environment and Services Settings window, the Configuration Wizard does not run any database automatically, even though domain JDBC is configured for PointBase database. In the Run Database Scripts dialog box, click Run Scripts screen, to load the respective database.
Note: If you select No in the Customize Environment and Services Settings window, the Configuration Wizard automatically populates the required PointBase database.

The following topics describe the steps required to change the JDBC and JMS file store settings in your domain:

Configure JDBC Data Sources

A JDBC data source contains a pool of database connections that are created when the data source instance is created—when it is deployed or targeted, or at server startup. Applications look up a data source on the JNDI tree, and then request a connection. When the applications no longer needs the connection, they return the connections to the connection pool in the data source.

Note: No databases are defined in the wls.jar template; so, if you select the WebLogic Server template as the basis for the domain, the Configure JDBC Data Sources window is not displayed.

The Configure JDBC Data Sources window lets you configure the JDBC data sources defined in your domain source. This step is optional. If required, you can test the connections to the database using the Test Connections button.

Note: The values that you specify for your database in this window must match the actual configuration of the database. For example, if you change the name of the PointBase database for a preconfigured domain in the DBMS name field, a PointBase database configured with that name must exist.
  1. Review the current list of JDBC data sources. Each data source is represented by a tab. You can view the information for a particular data source by selecting the corresponding tab. Default values may vary based on the domain source that you selected earlier.
  2. Add or change entries as required for your domain. Table 7-1 describes the fields of the Configure JDBC Data Sources window.
  3. Note: Fields marked with an asterisk are required.
    Table 7-1 Configure JDBC Data Sources
    Field
    Description
    Name*
    Enter a valid name for the JDBC data source. The name must be a string of characters and can include spaces.
    The name of the JDBC data source must be unique among all component names within the domain.
    JNDI name*
    From the drop-down list, select a JNDI name to which this data source is bound.
    • To add a new JNDI name, select Add New and enter a valid JNDI path.
    • To change an existing JNDI name, select the name and edit it.
    You can associate multiple JNDI names with a single data source.
    When an application looks up a JNDI path, a javax.sql.DataSource instance corresponding to the data source is returned.
    Database type*
    From the drop-down list, select the type of database to which you want to connect. If your DBMS is not listed, select Other.
    Driver*
    From the drop-down list, select the JDBC driver that you want to use to connect to the database. The list includes common JDBC drivers for the selected DBMS.
    If you selected Other in the Database type field, this field is not available.
    Class name*
    If you selected a DBMS in the Database type field, no action is required.
    If you selected Other in the Database type field, enter the full package name of the class that implements the java.sql.Driver interface for your DBMS.
    DBMS name*
    Enter the name of the database.
    If you selected Other in the Database type field, this field is not available.
    DBMS host*
    Enter the name of the server machine hosting the database.
    If you selected Other in the Database type field, this field is not available.
    DBMS port*
    Enter the port to be used to connect to the server. The default setting associated with the database selected is displayed.
    If you selected Other in the Database type field, this field is not available.
    JDBC URL*
    If you selected a DBMS in the Database type field, no action is required. If the Driver name has been set and a default URL exists, that URL is displayed in this field.
    If you selected Other in the Database type field, enter the URL that should be used to create the connections in the connection pool in the data source.
    User name*
    Enter the account login name required for connecting to the database.
    If you selected Other in the Database type field, this field is not available. This value can be specified in the Additional Properties field.
    User password*
    Enter a password that is valid for accessing the database. Valid values consist of a string of alphanumeric characters. The hyphen (-) and underscore ( _ ) characters are supported.
    This password overrides the password entered as part of the JDBC Properties.
    The value is encrypted.
    Confirm user password*
    Re-enter the user password.
    Known properties
    If you selected a DBMS in the Database type field, no action is required. This field displays the properties list that is passed to the JDBC driver for creation of physical database connections.
    If you selected Other in the Database type field, this field is blank and not available.
    Additional properties
    Enter any additional properties to be passed to the JDBC driver.
    If you specified Other in the Database type field, enter any properties to be passed to the JDBC driver, such as the property needed to specify the user.
    Supports global transactions
    If you selected an XA driver in the Driver field, Supports global transactions and Two-phase commit protocol are selected automatically. You cannot change the protocol.
    If you selected a non-XA driver in the Driver field, you can, if required, select Supports global transactions. Then, you can select one of the following protocols:
    • Logging Last Resource—With this option, the transaction branch in which the connection is used is processed as the last resource in the transaction and is processed as a one-phase commit operation. The result of the operation is written in a log file on the resource itself, and the result determines the success or failure of the prepare phase of the transaction. This option offers some performance benefits with greater data safety than Emulate Two-Phase Commit, but it has some limitations. For more information, see Understanding the Logging Last Resource Transaction Option in Configuring and Managing WebLogic JDBC.
    • Emulate two-phase commit—With this option, the transaction branch in which the connection is used always returns success for the prepare phase of the transaction. It offers performance benefits, but also has risks to data in some failure conditions. Select this option only if your application can tolerate heuristic conditions. For more information, see Understanding the Emulate Two-Phase Commit Transaction Option in Configuring and Managing WebLogic JDBC.
    • One phase commit (default)—With this option, a connection from the data source can be the only participant in the global transaction and the transaction is completed by using a one-phase commit optimization. If more than one resource participates in the transaction, an exception is thrown.
  4. After updating the settings, do one of the following:
    • If you want to test the data source connections to the specified databases, click Test Connections. The Test Data Source Connections window is displayed. For more information, see Test Data Source Connections.
    • If you do not want to test the connections to the database, click Next.

Test Data Source Connections

The Test Data Source Connections window allows you to test the connection to the database for each of the data sources defined in your domain, by using the JDBC URL defined for the database. This window is only displayed if you clicked Test Connections on the Configure JDBC Data Sources window.

A list of the data sources and the associated JDBC URLs is displayed.

  1. Make sure that the database to which you want to test the connections is running.
  2. Click Test for the connection that you want to test.
  3. The button changes to Cancel. You can press Cancel at any time to cancel the test. Once a test is in progress, all the other Test buttons are disabled.

    The Status field is blank for connections for which the test has not been initiated.

  4. Review the results of the test in the Connection Result Log pane.
  5. Perform the test for each data source, as required.
  6. Click OK to return to the Configure JDBC Data Sources window.

Run Database Scripts

A domain template might contain a set of SQL files organized by database type. If the domain template contains SQL files, you can run them while creating the domain, in the Run Database Scripts window. Database content for each of the data sources defined in your domain is set up by using pre-existing SQL or database loading files.

Notes: No databases are defined in the wls.jar template; so, if you selected the WebLogic Server template as the basis for the domain, the Configure JDBC Data Sources window and the Run Database Scripts window are not displayed.
Note: When you use PointBase in production mode, it is mandatory to run the database scripts. In development mode, this step is not mandatory.
Note: If you use the default PointBase database, you do not need to start the database server before running the scripts. For all other databases, the database server must be running to execute the SQL scripts.
  1. In the Available JDBC Data Sources pane, select the data source for which you want to run the scripts. The scripts that can be executed are displayed in the Available SQL Files and Database Loading Options.
  2. Select the database version from the DB Version drop-down menu.
  3. Click Run Scripts.
  4. All the scripts displayed in the Available SQL Files and Database Loading Options pane for the selected data source are executed, and the results are displayed in the Results pane. If you want to capture test output in a log file, select the Log File check box and specify the location of the log file.

  5. Repeat steps 1 through 3 for each data source for which you want to execute SQL scripts.
  6. Click Next.

Configure JMS File Stores

A JMS file store is a disk-based file in which persistent messages can be saved.

You can modify the JMS file stores that are configured in your domain, in the Configure JMS File Stores window, which is displayed when you click Next in the Run Database Scripts window. This step is optional.

  1. Review the current list of JMS file stores. Default values may vary based on the domain source that you selected earlier.
  2. Note: The wizard provides two display modes: a concise tabular view of all the defined components, and an individual view, in which each component is represented by a tab, and you view a particular component by selecting the corresponding tab. To toggle the display mode between table and tab formats, click Switch Display.
  3. Modify the settings, as required for your domain.
  4. Table 7-2 describes the fields of the Configure JMS File Stores window.

    Table 7-2 Configure JMS File Stores
    Field
    Description
    Name*
    Enter a name for the JMS file store. The name must be a string of characters and can include spaces.
    The name of the JMS file store must be unique among all component names within the domain.
    Directory
    Enter the path of the directory (in your system) in which the JMS file store resides.
    Synchronous write policy
    From the drop-down list, select one of the following synchronous write policies to determine how the file store writes data to the disk:
    • Cache-Flush: Transactions cannot be completed until all their write operations have been flushed to the disk.
    • Direct-Write: Write operations are performed directly to the disk. This policy is supported on Solaris and Windows. If this policy is active on an unsupported platform, the file store switches automatically to the cache-flush policy.
    • Disabled: Transactions are complete as soon as the writes are cached in memory. When this policy is active, completion of transactions does not depend on waiting for writes to reach the disk.
    This setting affects performance, scalability, and reliability.

    Note: The use of the direct-write policy is transactionally reliable in Solaris systems, but Windows systems may leave transaction data in the on-disk cache without writing it to disk immediately. This is not considered to be transactionally reliable because a power failure can cause loss of on-disk cache data, possibly resulting in lost and/or duplicate messages. For reliable writes using direct-write on Windows, either disable all write caching for the disk (enabled by default), or use a disk with a battery-backed cache. Some file systems, however, do not allow this value to be changed (for example, a RAID system that has a reliable cache).

    Note: If the JMS file store is used exclusively for paging non-persistent messages to the disk, the synchronous write policy is ignored.

  5. After updating the settings, click Next.

Review the domain settings and proceed with domain creation as described in Review the Domain Settings and Create the Domain.

Related Topics

Creating a Custom (User-Defined) File Store in Configuring WebLogic Server Environments


  Back to Top       Previous  Next