Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Developer's Guide

- Previous: Performance-Related Features
- Next: Chapter 8 Developing Java Clients

# Restrictions and Optimizations

This section discusses restrictions and performance optimizations that pertain to using CMP entity beans.

- Eager Loading of Field State

- Restrictions on Remote Interfaces

- Sybase Finder Limitation

- Date and Time Fields as CMP Field Types

- No Support for lock-when-loaded on Sybase and DB2

- Set RECURSIVE_TRIGGERS to false on MSSQL

## Eager Loading of Field State

By default, the EJB container loads the state for all CMP fields (excluding relationship, BLOB, and CLOB fields) before invoking the `ejbLoad` method of the abstract bean. This approach might not be optimal for entity objects with large state if most business methods require access to only parts of the state. If this is an issue, use the fetched-with element in `sun-cmp-mappings.xml` for fields that are used infrequently.

## Restrictions on Remote Interfaces

The following restrictions apply to the remote interface of an entity bean that uses CMP:

- Do not expose the `get` and `set` methods for CMR fields or the persistence collection classes that are used in container-managed relationships through the remote interface of the bean.

  However, you are free to expose the `get` and `set` methods that correspond to the CMP fields of the entity bean through the bean’s remote interface.

- Do not expose the container-managed collection classes that are used for relationships through the remote interface of the bean.

- Do not expose local interface types or local home interface types through the remote interface or remote home interface of the bean.

Dependent value classes can be exposed in the remote interface or remote home interface, and can be included in the client EJB JAR file.

## Sybase Finder Limitation

If a finder method with an input greater than 255 characters is executed and the primary key column is mapped to a VARCHAR column, Sybase attempts to convert type VARCHAR to type TEXT and generates the following error:

    com.sybase.jdbc2.jdbc.SybSQLException: Implicit conversion from datatype
    'TEXT' to 'VARCHAR' is not allowed.  Use the CONVERT function to run this
    query.

To avoid this error, make sure the finder method input is less than 255 characters.

## Date and Time Fields as CMP Field Types

If a CMP field type is a Java date or time type (`java.util.Date`, `java.sql.Date`, `java.sql.Time`, `java.sql.Timestamp`), make sure that the field value exactly matches the value in the database.

For example, the following code uses a `java.sql.Date` type as a primary key field:

    java.sql.Date myDate = new java.sql.Date(System.currentTimeMillis())
    beanHome.create(myDate, ...);

For some databases, this code results in only the year, month, and date portion of the field value being stored in the database. Later on if the client tries to find this bean by primary key as follows:

    myBean = beanHome.findByPrimaryKey(myDate);

the bean is not found in the database because the value does not match the one that is stored in the database.

Similar problems can happen if the database truncates the timestamp value while storing it, or if a custom query has a date or time value comparison in its WHERE clause.

For automatic mapping to an Oracle database, fields of type `java.util.Date`, `java.sql.Date`, and `java.sql.Time` are mapped to Oracle’s DATE data type. Fields of type `java.sql.Timestamp` are mapped to Oracle’s TIMESTAMP(9) data type.

## No Support for lock-when-loaded on Sybase and DB2

The lock-when-loaded consistency level is implemented by placing update locks on the data corresponding to a bean when the data is loaded from the database. There is no suitable mechanism available on Sybase and DB2 databases to implement this feature. Therefore, the lock-when-loaded consistency level is not supported on Sybase and DB2 databases.

## Set RECURSIVE_TRIGGERS to false on MSSQL

For version consistency triggers on MSSQL, the property `RECURSIVE_TRIGGERS` must be set to `false`, which is the default. If set to `true`, triggers throw a `java.sql.SQLException`.

Set this property as follows:

    EXEC sp_dboption 'database-name', 'recursive triggers', 'FALSE'
    go

You can test this property as follows:

    SELECT DATABASEPROPERTYEX('database-name', 'IsRecursiveTriggersEnabled')
    go

- Previous: Performance-Related Features
- Next: Chapter 8 Developing Java Clients

- © 2010, Oracle Corporation and/or its affiliates