How do I configure Web Load Balancer using XML?

How do I work with CMP Beans?

This section discusses the various attributes of container-managed persistence (CMP) entity beans, their relationships, object relational (OR) mappings, finder queries, and how to use these entity beans with Server.

What is Container Managed Persistence?

CMP provides a standard mechanism for implementing persistent business components in the J2EE component model. It defines the life cycle of entity bean instances and management model for entity bean's persistence state and relationships. It ensures that an entity bean is portable across all J2EE-compliant EJB containers.

Persistence is provided by the container transparently through generated implementation classes for entity beans. Entity beans are logically independent of the underlying datasource where the persistence state is stored.

Entity beans rely on CMP to generate methods that perform persistent data access for entity bean instances. These generated methods transfer data between entity bean instances and the underlying resource manager. Persistence is handled by the container at runtime. The advantage of CMP is that the entity bean can be logically independent of the datasource in which the entity is stored.

What is Object Relational Mapping?

OR mapping for CMP 1.1 beans involves mapping the beans to their database schemas. OR mapping for CMP 2.0 beans involves mapping the beans to the database schemas and container-managed relationships (CMR).

How do I map Container-Managed Persistence Fields?

Note: CMP1.1 beans can have a Byte Array as container managed field.

Example: A CMP field with type java.lang.String should not be mapped with a number column type. It is recommended to map this type to varchar. Refer to the Type Conversion tables for more information.

Click a CMP bean node, and click the CMFields tab. Use the existing tables so that the Server generates the appropriate queries to create, load, store, and remove CMP beans.

To map a CMP bean to the database schemas:

• Select a datasource from the Data Source drop-down list.
• Select a schema name from the Schema Name drop-down list.
• Select a table name from the Table Name drop-down list.
• Select the appropriate database attributes from the DB Attribute field and map them to the CMP fields in the table.

What are Finder Queries? How do I use them?

Applications that use CMP 2.0 beans, specify finder queries in a vendor-neutral language - Enterprise Java Bean Query Language (EJB QL) - during packaging. There are no standard finder query languages for applications that use CMP 1.1 beans. Queries for finder methods for such applications are specific to vendors.

Queries for finder methods in CMP 1.1 beans are resolved during deployment for applications deployed on Server. These queries define the behavior of the finder methods.

Note: For more information on how to define SQL Queries, read Writing SQL Queries for EJBs.

How do I Map Finder Queries?

To create a new query, click New. This opens the Query Wizard, which helps generate SQL queries for CMP 1.1 beans. A generated query is stored in the bean’s Bean Properties file. When you save or deploy the .jar containing the bean, a file called queries.props is generated and stored in the .jar.

To import existing queries, click Import. This opens the Query Viewer, which helps to import existing queries. This facility is used when transferring queries prepared during development to a deployment site or when relocating .ears.

How do I use Container Managed Relationships?

Entity beans can have either uni-directional or bi-directional relationships with other beans. You can define and store these relationships in the ejb-jar.xml file.

Server supports the following four types of relationship mappings according to the EJB 2.0 specification:

• One-to-One
• One-to-Many
• Many-to-One
• Many-to-Many

Note: Server does not support relationships between beans that are mapped to different datasources, but does support uni-directional self-relationships and bi-directional self-relationships.

What are Uni-directional Relationships?

Example: If entity A and entity B are in a one-to-one, uni-directional relationship and if the direction is from entity A to entity B, then entity A is aware of entity B, but entity B is not aware of entity A. This type of relationship is implemented with a container managed relationship (CMR) field on the entity bean from which navigation is possible and where there is no related CMR field on the target entity bean.

What are Bi-directional Relationships?

Example: If entity A and entity B are in a one-to-one bi-directional relationship, both beans are aware of each other.

What are Preloading Container Managed Relationships?

In the case of Lazy Loading the number of database round trips are more which has an impact on performance. Preloading of CMRs aims at minimizing the database round trips for relationship access hence improving their performance.

Performance Advantage with Container Managed Relationship Pre-loading

In case of Lazy Loading, there would be two database round trips for a one-to-one relationship - one query to associate the target identity and another query to load the target entity's state.

While pre-loading a single query associates the identity as well as the state during relationship access, in case of one-to-many relationship access, the number of database roundtrips can be reduced to one single query from n-number of queries using pre-loading option.

Note: Pre-loading is not done for non-transactional relationship access.

How do I configure Relationship Preloading in Deploy Tool?

How do I use Deferred Primary Key Mapping?

Server enables you to represent columns that are not mapped to CMFields as deferred Primary Key (PK) fields. During deployment, a deployer can choose one or more columns from the corresponding table to define the PK. The container provides a key generation algorithm for these deferred keys, which is used to insert unique values for PK columns. By default, a String value key generator is provided. It is also possible to plug in an integer value key generator.

The Server does not support deferred PKs that contain Foreign Key (FK) constraints. Using entity beans with deferred PK-type specifications limits the client application programming model because clients that are written before deploying the entity bean may not use methods that are based on the PK-type.

For deferred PKs, the PK-type is specified as java.lang.Object in the deployment descriptor.

How do I remove Beans having relationships?

To cascade the deletion of one entity object automatically to another, use the cascade-delete mechanism.

How do I use Cascade Delete?

Cascade Delete can only be specified for an EJB-relationship-role element contained in an EJB-relation element if the other EJB-relationship-role element in the same EJB-relation element specifies a multiplicity of One. This option cannot be specified for a many-to-many relationship.

This option deletes only the entity object or objects in the relationship for which it is specified. It does not cascade delete other entity objects, unless they are participants in relationship roles for which cascade-delete has also been specified.

How do I resolve JOIN conditions?

Choose the CMRelations tab in the bean node to view the CMRs. This panel appears only for CMP 2.0 beans. Server resolves relationships automatically between CMP 2.0 beans.

Use this panel to further edit the JOIN conditions as well as view existing CMRs.

To edit the JOIN conditions using the Deploy Tool:

• Select the relation from the Relationships field.
• Click the JOIN Condition button. This displays the JOIN Condition window.
• Edit the JOIN Condition and click Add.
• Close the JOIN Condition panel. The JOIN condition is edited in the relation.

Example: The first table, SalesOrder, contains SalesOrderId, which is defined as the PK. The second table, LineItem, contains SalesOrderId, which is the FK related to the PK of SalesOrder.

Specify the join condition using the Deploy Tool as shown above.

How do I use Deferred Primary Key Mapping?

Select the bean node in the .jar and choose the PrimaryKey tab.

The attributes in this panel are:

• Data Source: Provides a list of the available data sources.
• Table Name: Provides a list of tables in the database.
• PK: Has a yellow key as its icon when enabled. Click a key icon for a database attribute to make it a PK for the table. Multiple database attributes can function as the PK class. The CMFields and CMRelations tabs are enabled only after the PK class is selected.
  Note: When the Primary Key panel opens during deployment, the datasource and Table Name fields are disabled in the CMFields panel.
• DB Attribute: Displays all the database attributes in the table. Select those DB attributes or columns that do not correspond to a CMP field.

How do I convert data for query results?

The data conversion table lists all the conversions from SQL types to Java types that are supported through getXXX methods of Prepared Statement. For example, you can read an SQL VARCHAR value as a string using getString, but you cannot read an SQL FLOAT as java.sql.Date.

If you attempt an illegal conversion, or if a data conversion fails, an SQLException is raised. For example, you cannot call getInt on an SQL VARCHAR value foo.

How do I use ResultSet.getXXX methods to retrieve common SQL data types?

What are the limitations in Mapping SQL data types to Java types?

You should provide appropriate Java mappings for the common SQL data types. Ensure that you have type information to store and retrieve parameters and recover results from SQL statements.

A Java data type may not be isomorphic to the SQL data type. For example, you can represent both fixed length and variable length SQL arrays as variable length Java arrays as Java has no fixed length arrays. Server uses Java strings though they are not a precise match for any SQL CHAR type.

The following table lists the default Java mappings for various common SQL data types. These types are not entirely supported by all databases.

Table 1: Default Java Mappings for common SQL Data Types

The following table lists reverse mapping from Java types to SQL types.

Table 2: Details for Reverse Mapping from Java to SQL Types

Java	Type	-	Java	Type
String	VARCHAR or LONGVARCHAR	-	byte	VARBINARY or LONGVARBINARY
java.math.BigDecimal	NUMERIC	-	boolean	BIT
byte	TINYINT	-	short	SMALLINT
int	INTEGER	-	long	BIGINT
float	REAL	-	double	DOUBLE
java.sql.Date	DATE	-	java.sql.Time	TIME
java.sql.Timestamp	TIMESTAMP	-	-	-

The mapping for a String is VARCHAR but, it is a LONGVARCHAR if the given value exceeds the limit of VARCHAR values in the driver. This is the case for byte, VARBINARY, and LONGVARBINARY.

Table 3: Details of the conversions from SQL to Java Types

Methods\Types	tinyint	smallint	integer	bigint	real	float	double	decimal	numeric	bit	char	varchar	longvarchar	binary	varbinary	longvarbinary	date	time	timestamp
getByte	R	x	x	x	x	x	x	x	x	x	x	x	x	-	-	-	-	-	-
getShort	x	R	x	x	x	x	x	x	x	x	x	x	x	-	-	-	-	-	-
getInt	x	x	R	x	x	x	x	x	x	x	x	x	x	-	-	-	-	-	-
getLong	x	x	x	R	x	x	x	x	x	x	x	x	x	-	-	-	-	-	-
getFloat	x	x	x	x	R	x	x	x	x	x	x	x	x	-	-	-	-	-	-
getDouble	x	x	x	x	x	R	R	x	x	x	x	x	x	-	-	-	-	-	-
getBigDecimal	x	x	x	x	x	x	x	R	R	x	x	x	x	-	-	-	-	-	-
getBoolean	x	x	x	x	x	x	x	x	x	R	x	x	x	-	-	-	-	-	-
getString	x	x	x	x	x	x	x	x	x	x	R	R	x	x	x	x	x	x	x
getBytes	-	-	-	-	-	-	-	-	-	-	-	-	-	R	R	x	-	-	-
getDate	-	-	-	-	-	-	-	-	-	-	x	x	x	-	-	-	R	-	x
getTime	-	-	-	-	-	-	-	-	-	-	x	x	x	-	-	-	-	R	x
getTimestamp	-	-	-	-	-	-	-	-	-	-	x	x	x	-	-	-	x	-	R
getAsciiStream	-	-	-	-	-	-	-	-	-	-	x	x	R	x	x	x	-	-	-
getUnicodeStream	-	-	-	-	-	-	-	-	-	-	x	x	R	x	x	x	-	-	-
getBinaryStream	-	-	-	-	-	-	-	-	-	-	-	-	-	x	x	R	-	-	-
getObject	x	x	x	x	x	x	x	x	x	x	x	x	x	x	x	x	x	x	x

© Pramati Technologies 2007	Runs on Pramati Server | Feedback | Legal