Configuring the Waveset Repository

This section describes how to configure some commonly configured properties in the Waveset repository.

Do not modify properties in the Waveset repository unless you are very familiar with repository databases and understand the consequences of making these changes.

Disabling Automatic Connection Pooling

If you are using a DataSource, set the connectionPoolDisable attribute to true in the RepositoryConfiguration object to disable automatic internal connection pooling in the Waveset repository.

For example, setting <RepositoryConfiguration connectionPoolDisable=’true’> allows you to avoid having two connection pools (one for Waveset and one for your application server).

You can see the current connectionPoolDisable setting in the ObjectRepository JMX MBean.

Using Inline Attributes

You can edit the RepostioryConfiguration object to enhance the performance of searches against specific, single-valued attributes. For example, you might edit this object to add an extended attribute, such as employeeID, that is used to search for Users or as a correlation key.

The default RepositoryConfiguration object looks like the following example:

<RepositoryConfiguration ... >
   <TypeDataStore Type="User" ... attr1="MemberObjectGroups", 
attr2="lastname" attr3="firstname" attr4="" attr5="">
   </TypeDataStore>
</RepositoryConfiguration>

The ellipses represent XML attributes that are not relevant here.

Each of the attr1, attr2, attr3, attr4, and attr5 XML attributes specifies a single-valued attribute to be copied into the waveset.userobj table. The waveset.userobj table can contain up to five inline attributes. The attribute value named by attr1 in RepositoryConfiguration will be copied into the “attr1” database column in this table.

Inline attributes are stored in the base object table for a Type (rather than as rows in the child attribute table).

Using inline attributes improves the performance of repository queries against those attributes. (Because inline attributes reside in the main “object” table, queries against inline attributes are faster than those against non-inline attributes, which are stored in the child “attribute” table. A query condition against a non-inline attribute requires a “join” to the attribute table.)

By default, Waveset uses the MemberObjectGroups, lastname, and firstname inline attributes.

• You can add two more attributes to enable faster searching, as long as those attributes are queryable.

  For example, if your deployment contains an employeeID extended attribute, adding that attribute inline will improve the performance of repository searches against that attribute.

• If you do not need lastname or firstname, you can remove them or replace them with other attributes.

• Do not remove MemberObjectGroups. Waveset uses this attribute internally to speed up authorization checks.

Limiting Concurrent Connections

Every public repository method acquires a connection when the method begins and then releases that connection when the method exits. This connection is almost always a JDBC connection because the repository almost always accesses a DBMS. The method releases the connection whether it completes successfully or unsuccessfully.

You can configure the number of concurrent connections by modifying the maxConcurrentConnections value in the RepositoryConfiguration object.

• The number of concurrent JDBC connections is unlimited by default (maxConcurrentConnections=0). The Waveset repository can request as many connections as necessary to serve each concurrent repository request.

• You specify a maximum number of concurrent connections that the repository can use at one time by changing the maxConcurrentConnections value to a positive integer. In effect, this setting limits the number of calls to the repository that can be actively executing at any one time.

If the repository reaches the configured limit, calls to the repository will wait until the number of connections being used by the repository falls back below the limit. The repository might appear to slow down, or even stop, if this is necessary to stay within the specified number of connections.

Any limit on the number of concurrent connections applies whether the repository pools connections or not. In other words, maxConcurrentConnections is unaffected by connectionPoolDisable.

To configure the maxConcurrentConnections value, you must edit the RepositoryConfiguration object from the System Settings debug page (http://host:port/idm/debug/session.jsp),

1. Select Configuration from the menu located next to the List Objects button.

2. Click the List Objects button to view all of the Configuration-type objects.

3. Locate RepositoryConfiguation and click Edit.

4. When the Checkout Object: Configuration, #ID#REPOSITORYCONFIGURATION page displays (similar to the following example), locate maxConcurrentConnections and modify the existing value as needed.

   <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE Configuration PUBLIC 'waveset.dtd' 'waveset.dtd'> <!-- MemberObjectGroups="#ID#Top" extensionClass="RepositoryConfiguration" id="#ID#RepositoryConfiguration" name="RepositoryConfiguration"--> <Configuration id='#ID#RepositoryConfiguration' name='RepositoryConfiguration' lock='Configurator#1251229174812' creator='getRepositoryConfiguration(boolean)' createDate='1249052436640' repoMod='1249048790203' type= 'RepositoryConfiguration'> <Extension> <RepositoryConfiguration instanceOf= 'com.waveset.repository.RepositoryConfiguration' lockTimeoutMillis='300000' maxConcurrentConnections='0' blockRowsGet='1000' blockRowsList='10000' maxAttrValLength='255' maxLogAcctAttrChangesLength='4000' maxLogMessageLength='255' maxLogXmlLength='2147483647' maxLogAcctAttrValueLength='128'maxLogParmValueLength='128' maxXmlLength='2147483647' maxSummaryLength='2048' optimizeReplaceAttributes= 'true' maxInList='1000' maxDelSet='1000' mcDBCall='10' mcDeleteAttrVal='3' mcInsertAttrVal='15' mcUpdateAttrVal='20' connectionPoolDisable='false' changeScanInterval='5000' changePropagationDelay='3000' changeAgeOut='60000'> <RelocatedTypes> <TypeDataStore typeName='User' deleteDestroyInterval='1' attr1='MemberObjectGroups' attr2='lastname' attr3='firstname'> </TypeDataStore> </RelocatedTypes> </RepositoryConfiguration> </Extension> <MemberObjectGroups> <ObjectRef type='ObjectGroup' id='#ID#Top' name='Top'/> </MemberObjectGroups> </Configuration>L

5. Save your changes.

For more information about which object types are stored in each set of tables, see Data Classes.

Using preferPreparedStatement

JDBC supports execution of two types of SQL statements:

• Statement

• PreparedStatement

Generally, a PreparedStatement is more efficient for the DBMS because the DBMS server can cache and reuse a PreparedStatement for multiple executions, avoiding the cost of SQL parsing and optimizer selections. To get the benefit of this caching, Waveset associates a PreparedStatement with a JDBC connection. When Waveset is going to issue the same SQL statement multiple times using the same connection, it automatically uses a PreparedStatement.

However, most of the JDBC operations performed by Waveset do not share a connection between JDBC calls. Most JDBC operations are the result of the application server processing an HTTP request through a JSP, so that the processing thread acquires a JDBC connection when needed and releases that connection when it is done. Consequently, you must do some additional work to get the benefits of using PreparedStatements.

Many application servers provide DataSource implementations that provide both connection pooling and implicit statement caching. Implicit statement caching is the ability of the DataSource or connection pool to implicitly cache JDBC statements and associate them with the connection.

If you configure Waveset to use an application server DataSource, you must have both of these features to benefit from using Waveset's preferPreparedStatement repository option. If you are not using an application server DataSource, if the DataSource is not configured to use a connection pool, or if the connection pool does not support implicit statement caching, using preferPreparedStatement causes decreased performance because the DBMS cannot reuse the statement.

Waveset code is not structured to associate a statement with a connection, except in a few circumstances, so Waveset depends on the DataSource or connection pool to perform this caching. If you configure the Waveset repository to use a DataSource or connection pool that performs implicit statement caching, and you enable preferPreparedStatement=true in the RepositoryConfiguration configuration object, Waveset can use PreparedStatement for object lock/unlock operations and most get operations, which potentially results in performance improvements. The Waveset ObjectRepository has a JMX MBean that indicates the setting of the preferPreparedStatement switch and the number of Statement/PreparedStatement requests made by the Waveset server.

You can see the current preferPreparedStatement setting in the ObjectRepository JMX MBean.