| Oracle® Containers for J2EE Orion CMP Developer's Guide 10g Release 3 (10.1.3.1) Part Number B28220-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Orion CMP Developer's Guide 10g Release 3 (10.1.3.1) Part Number B28220-01 |
|
|
View PDF |
This chapter describes the various options that you must configure in order to use an EJB 2.0 entity bean with container-managed persistence.
Table 5-1 lists these options and indicates which are basic (applicable to most applications) and which are advanced (applicable to more specialized applications).
Table 5-1 Configurable Options for an EJB 2.0 Entity Bean With Container-Managed Persistence
|
Note: Oracle suggests that you use JDeveloper IDE for configuring your entity beans with container-managed persistence. The reason is that JDeveloper is capable of managing complex mappings between the entity beans and the database tables. See "Configuring Container-Managed Relationship Fields" and "Using JDeveloper" for more information. |
For more information, see the following:
Each entity bean instance has a primary key that uniquely identifies it from other instances. You must declare the primary key (or the fields contained within a complex primary key) as a container-managed persistent field in the deployment descriptor.
This section describes the following aspects of the primary key configurations:
All fields within the primary key are restricted to either primitive, serializable, or types that can be mapped to SQL types. You can define your primary key in one of the following ways:
Define the type of the primary key to be a well-known type. The type is defined in the <prim-key-class> element in the deployment descriptor. The data field that is identified as the persistent primary key is identified in the <primkey-field> element in the deployment descriptor. The primary key variable that is declared within the bean class must be declared as public.
The advanced option of defining the primary key is to define its type as a serializable object within a serializable <NAME>PK class. This class is declared in the <prim-key-class> element in the deployment descriptor. See "Configuring Primary Key Class" for more information.
Specify an automatically generated primary key: if you specify a java.lang.Object as the primary key class type in <prim-key-class>, but do not specify the primary key name in <primkey-field>, then the primary key is automatically generated by the container. See "Configuring Automatic Primary Key Generation" for more information.
Example 5-1 Defining a Primary Key of a Well-Known Type Within the Deployment Descriptor
For a simple CMP, you can define your primary key to be a well-known type by defining the data type of the primary key within the deployment descriptor. Example 5-1 shows how to define the primary key (employee number) as a java.lang.Integer:
<enterprise-beans>
<entity>
<display-name>Employee</display-name>
<ejb-name>EmployeeBean</ejb-name>
<local-home>employee.EmployeeLocalHome</local-home>
<local>employee.EmployeeLocal</local>
<ejb-class>employee.EmployeeBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.Integer</prim-key-class>
<reentrant>False</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>Employee</abstract-schema-name>
<cmp-field><field-name>empNumber</field-name></cmp-field>
<cmp-field><field-name>empName</field-name></cmp-field>
<cmp-field><field-name>salary</field-name></cmp-field>
<primkey-field>empNumber</primkey-field>
</entity>
...
</enterprise-beans>
Once defined, the container creates a column in the entity bean table for the primary key and maps the primary key defined in the deployment descriptor to this column.
Within the orion-ejb-jar.xml file, the primary key is mapped to the underlying database persistence storage by mapping the container-managed persistent field or primary key field defined in the ejb-jar.xml file to the database column name. In the following orion-ejb-jar.xml fragment, the EmpBean persistence storage is defined as the EMP table in the database that is defined in the jdbc/OracleDS data source. Following the <entity-deployment> element definition (see Table A-1, "Attributes of the <entity-deployment> Element"), the primary key, empNumber, is mapped to the EMPNUMBER column in the EMP table, and the empName and salary persistent fields are mapped to EMPNAME and SALARY columns respectively in the EMP table:
<entity-deployment name="EmpBean" ...table="EMP" data-source="jdbc/OracleDS"...>
<primkey-mapping>
<cmp-field-mapping name="empNumber" persistence-name="EMPNUMBER" />
</primkey-mapping>
<cmp-field-mapping name="empName" persistence-name="EMPNAME" />
<cmp-field-mapping name="salary" persistence-name="SALARY" />
...
If your primary key is more complex than a simple data type, your primary key must be a class that is serializable of the name <NAME>PK. You define the primary key class within the <prim-key-class> element in the deployment descriptor.
The primary key variables must adhere to the following:
Be defined within a <cmp-field><field-name> element in the deployment descriptor. This enables the container to manage the primary key fields.
Be declared within the bean class as public and restricted to be either primitive, serializable, or types that can be mapped to SQL types.
The names of the variables that make up the primary key must be the same in both the <cmp-field><field-name> elements and in the primary key class.
Within the primary key class, you implement a constructor for creating a primary key instance. Once the primary key class is defined in this manner, the container manages the class.
Example 5-2 Defining the Primary Key Class
Example 5-2 places the employee number within a primary key class.
package employee;
public class EmployeePK implements java.io.Serializable {
public Integer empNumber;
public EmployeePK() {
this.empNumber = null;
}
public EmployeePK(Integer newEmpNumber) {
this.empNumber = newEmpNumber;
}
}
Example 5-3 Declaring the Primary Key Class in the Deployment Descriptor
The primary key class is declared in the deployment descriptor within the <prim-key-class> element, and each of its variables are declared within a <cmp-field><field-name> element, as Example 5-3 shows:
<enterprise-beans>
<entity>
<description>no description</description>
<display-name>EmployeeBean</display-name>
<ejb-name>EmployeeBean</ejb-name>
<local-home>employee.EmployeeLocalHome</local-home>
<local>employee.EmployeeLocal</local>
<ejb-class>employee.EmployeeBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>employee.EmployeePK</prim-key-class>
<reentrant>False</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>Employee</abstract-schema-name>
<cmp-field><field-name>empNumber</field-name></cmp-field>
<cmp-field><field-name>empName</field-name></cmp-field>
<cmp-field><field-name>salary</field-name></cmp-field>
</entity>
...
</enterprise-beans>
Once you define the primary key, the container creates a column in the entity bean table for the primary key and maps the primary key class declared in the deployment descriptor to this column.
The persistent fields are mapped in the orion-ejb-jar.xml in the same manner as described in the "Configuring Primary Key" section. With a complex primary key, the mapping contains more than a single field; thus, the <cmp-field-mapping> element of the <primkey-mapping> element contains another <fields> subelement. Every field of the primary key is defined in a separate <cmp-field-mapping> element within the <fields> element, similar to the following:
<primkey-mapping>
<cmp-field-mapping>
<fields>
<cmp-field-mapping name="empNumber" persistence-name="EMPNUMBER" />
</fields>
</cmp-field-mapping>
</primkey-mapping>
|
Note: If you have a complex primary key that contains a foreign key, you need to apply a special mapping. See "Configuring Foreign Key in a Composite Primary Key" for more information. |
In the EJB 2.0 specification, the primary key for an entity bean must be initialized within the ejbCreate method. However, in this method you cannot set any relationship that this bean has to another bean. The earliest when you can set this relationship in a foreign key is in the ejbPostCreate method.
That said, if you have a foreign key within a composite primary key, you face the following problem: you must set all fields within the composite primary key in the ejbCreate method, but you cannot set the foreign key in this method.
The following hypothetical scenario models the way around this problem: an order can contain one or more items; the order bean has many items in it; each item belongs to an order. The primary key for the item is a composite primary key consisting of the item identifier and the order identifier. The order identifier is a foreign key that points to the order.
You would have to modify the deployment descriptors and bean implementation to add a placeholder persistent field that mimics the actual foreign key field. This field is set during the ejbCreate method. However, both the placeholder persistent field and the foreign key point to the same database column. The actual foreign key is updated during the ejbPostCreate method.
|
Note: Modify theejb-jar.xml file with the placeholder persistent field and the foreign key. Deploy the application with <autocreate-tables> element in the orion-application.xml file set to false to automatically generate the orion-ejb-jar.xml file, without creating any tables. Then modify the orion-ejb-jar.xml file to point to the correct database columns, set <autocreate-tables> element to true, and redeploy. |
Example 5-4 Modifying the Deployment Descriptor and the Bean Code to Accommodate a Foreign Key Within a Primary Key
Example 5-4 demonstrates how to modify both deployment descriptors and the bean implementation.
In the order scenario, each order contains one or more items. The OrderBean represents the order, and the OrderItemBean represents the items in the order. Each item has a primary key that consists of the item number and the order number to which it belongs. Thus, the primary key for the item contains a foreign key that points to an order bean.
To adjust for a composite primary key, modify the ejb-jar.xml file in the following way:
Define a persistent field in the primary key as a placeholder for the foreign key. This placeholder should be used in the composite primary key class definition.
In the Example 5-4, an orderId persistent field is defined in a <cmp-field> element. The orderId and itemId persistent fields are used to identify the composite primary key in the OrderItemPK.java.
Define the foreign key outside the primary key definition in its own <cmr-field> element in the <relationships> section.
In the Example 5-4, the belongToOrder foreign key is defined in a <cmr-field> element for the OrderItemBean, defining the relationship from the item to the order.
<entity>
<ejb-name>OrderItemBean</ejb-name>
<local-home>OrderItemLocalHome</local-home>
<local>OrderItemLocal</local>
<ejb-class>OrderItemBean</ejb-class>
...
<cmp-field><field-name>itemId</field-name></cmp-field>
<cmp-field><field-name>orderId</field-name></cmp-field>
<cmp-field><field-name>price</field-name></cmp-field>
<prim-key-class>OrderItemPK</prim-key-class>
...
</entity>
<relationships>
<ejb-relation>
<ejb-relation-name>Order-OrderItem</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>
Order-Has-OrderItems
</ejb-relationship-role-name>
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>OrderBean</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>items</cmr-field-name>
<cmr-field-type>java.util.Collection</cmr-field-type>
</cmr-field>
</ejb-relationship-role>
<ejb-relationship-role>
<ejb-relationship-role-name>
OrderItems-from-Order
</ejb-relationship-role-name>
<multiplicity>Many</multiplicity>
<cascade-delete/>
<relationship-role-source>
<ejb-name>OrderItemBean</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>belongToOrder</cmr-field-name>
</cmr-field>
</ejb-relationship-role>
...
The OrderItemPK.java class defines the contents of the complex primary key, as follows:
public class OrderItemPK implements java.io.Serializable {
public Integer itemID;
public Integer orderID;
public OrderItemPK() {
this.itemId = null;
this.orderId = null;
}
public OrderItemPK(Integer newItemId, Integer newOrderId) {
this.itemId = newItemId;
this.orderId = newOrderId;
}
public boolean equals(Object o) {
if (o instanceof OrderItemPK) {
OrderItemPK pk = (OrderItemPK) o;
if (pk.itemId.intValue() == itemId.intValue() &&
pk.orderId.intValue() == orderId.intValue()) {
return true;
}
}
return false;
}
public int hashCode() {
return itemId.hashCode() * orderId.hashCode();
}
}
If you consider the automatically created database tables sufficient, you do not need to modify the orion-ejb-jar.xml file. However, if you need to map to existing database tables, then you modify the orion-ejb-jar.xml file to point to these tables (see "Configuring Explicit Mapping of Relationship Fields to the Database" for more information).
After the automatic generation of the orion-ejb-jar.xml file, copy it into your development directory. The database column names are defined in the persistence-name attributes in each of the persistent and relationship field name mappings. Ensure that the persistence-name attributes for both the placeholder persistent field and foreign key are the same.
The following is the orion-ejb-jar.xml file for the Order/OrderItem example:
<entity-deployment name="OrderItemBean" table="ORDER_ITEM"> <primkey-mapping> <cmp-field-mapping name="itemId" persistence-name="Item_ID" /> <cmp-field-mapping name="orderId" persistence-name="Order_ID" /> </primkey-mapping> <cmp-field-mapping name="price" persistence-name="Price" /> <cmp-field-mapping name="belongToOrder"> <entity-ref home="OrderBean"> <cmp-field-mapping name="belongToOrder" persistence-name="Order_ID" /> </entity-ref> </cmp-field-mapping> </entity-deployment> <entity-deployment name="OrderBean" table="ORDER"> <primkey-mapping> <cmp-field-mapping name="orderId" persistence-name="Order_ID" /> </primkey-mapping> <cmp-field-mapping name="orderDesc" persistence-name="Order_Description" /> <cmp-field-mapping name="items"> <collection-mapping table="ORDER_ITEM"> <primkey-mapping> <cmp-field-mapping name="OrderBean_orderId"> <entity-ref home="OrderBean"> <cmp-field-mapping name="OrderBean_orderId"> </entity-ref> </cmp-field-mapping> </primkey-mapping> <value-mapping type="OrderItemLocal"> <cmp-field-mapping name="OrderItemBean_itemId"> <entity-ref home="OrderItemBean"> <cmp-field-mapping name="OrderItemBean_itemId"> <cmp-field-mapping name="OrderItemBean_itemId"> </fields> </cmp-field-mapping> </entity-ref> </cmp-field-mapping> </value-mapping> </collection-mapping> </cmp-field-mapping> </entity-deployment>
The following takes place in the <entity-deployment> (see Table A-1, "Attributes of the <entity-deployment> Element") section for the OrderItemBean of the orion-ejb-jar.xml file for the Order/OrderItem example:
The table is defined in the table attribute, which is ORDER_ITEM in this example.
The column name for the itemId is defined in the persistence-name attribute as Item_ID.
The column name for the placeholder persistent field, orderId, is defined in the persistence-name attribute as Order_ID.
The foreign key, belongToOrder, is mapped to the database column, Order_ID, which is the same column as the placeholder persistent field, orderId.
Both the foreign key (belongToOrder), and the placeholder persistent field (orderId) must point to the same database column.
Finally, you must update the bean implementation to work with both the placeholder persistent field and the foreign key, as follows:
In the ejbCreate method, do the following:
Create the placeholder persistent field that takes the place of the foreign key field.
Set a value in the placeholder persistent field in the ejbCreate method. This value is written out to the foreign key field in the database table.
In the ejbPostCreate method, set the foreign key to the value in the duplicate persistent field.
|
Note: Since the foreign key is a part of a primary key, you can only set it once. |
In the Order/OrderItem example, the orderId persistent field is set in the ejbCreate method, whereas the belongToOrder relationship field is set in the ejbPostCreate method, as follows:
public OrderItemPK ejbCreate(OrderItem orderItem) throws CreateException {
setItemId(orderItem.getItemId());
setOrderId(orderItem.getOrderId());
setPrice(orderItem.getPrice());
return new OrderItemPK(orderItem.getItemId(),orderItem.getOrderId());
}
public void ejbPostCreate(OrderItem orderItem) throws CreateException {
// right after the bean has been created
try {
Context ctx = new InitialContext();
OrderLocalHome orderHome =
(OrderLocalHome)ctx.lookup("java:comp/env/OrderBean");
OrderLocal order = orderHome.findByPrimaryKey(orderItem.getOrderId());
setBelongToOrder(order);
}
catch(Exception e) {
e.printStackTrace();
throw new EJBException(e);
}
}
The following is the code for the OrderItem object that is passed into the ejbCreate and ejbPostCreate methods:
public class OrderItem implements java.io.Serializable {
private Integer itemId;
private Integer orderId;
private Double price;
public OrderItem(Integer itemId, Integer orderId, Double price) {
this.itemId = itemId;
this.orderId = orderId;
this.price = price;
}
public Integer getItemId() {
return itemId;
}
public void setItemId(Integer itemId) {
this.itemId = itemId;
}
public Integer getOrderId() {
return orderId;
}
public void setOrderId(Integer orderId) {
this.orderId = orderId;
}
public Double getPrice() {
return price;
}
public void setPrice(Double price) {
this.price = price;
}
public boolean equals(Object other) {
if (other instanceof OrderItem) {
OrderItem orderItem = (OrderItem)other;
if (itemId.equals(orderItem.getItemId()) &&
orderId.equals(orderItem.getOrderId()) &&
price.equals(orderItem.getPrice()) ) {
return true;
}
}
return false;
}
}
If you specify a java.lang.Object as the primary key class type in <prim-key-class> element of your deployment descriptor, but do not specify the primary key name in <primkey-field> element, then the primary key is automatically generated by the container, as follows:
<enterprise-beans>
<entity>
<display-name>Employee</display-name>
<ejb-name>EmployeeBean</ejb-name>
<local-home>employee.EmployeeLocalHome</local-home>
<local>employee.EmployeeLocal</local>
<ejb-class>employee.EmployeeBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.Object</prim-key-class>
<reentrant>False</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>Employee</abstract-schema-name>
<cmp-field><field-name>empNumber</field-name></cmp-field>
<cmp-field><field-name>empName</field-name></cmp-field>
<cmp-field><field-name>salary</field-name></cmp-field>
</entity>
...
</enterprise-beans>
Once defined, the container creates a column called autoid in the entity bean table for the primary key of type LONG. The container uses random numbers for the primary key values. This is generated in the orion-ejb-jar.xml for the bean, as follows:
<primkey-mapping>
<cmp-field-mapping name="auto_id" persistence-name="autoid"/>
</primkey-mapping>
Container-managed persistent fields represent simple data types that are persisted to database tables. These fields define the state of an entity bean. These fields are direct attributes of a bean. For more information about persistent fields, see "Container-Managed Persistent Fields".
In entity beans with container-managed persistence, you define the persistent data both in the bean instance and in the deployment descriptor using the following:
Accessor methods (getter and setter) in the bean instance: For each persistent field, both a getter and a setter method is created. The data type of the parameter returned from the getter and passed into the setter defines the simple data type of the field. The name of the field is designated by the name of the getter and setter methods.
The following code shows a getter and a setter for the employee name persistent field. A String that is returned from the getter and passed into the setter is a simple data type of the field. If you remove the "get" and "set" from the method names, and then lower the case of the first letter, you have the persistent field name. In the following example, empName is the persistent field name:
public abstract String getEmpName() throws RemoteException; public abstract void setEmpName(String empName) throws RemoteException;
The deployment descriptor declares these fields as persistent. Each field name must be defined in a <cmp-field><field-name> element in the deployment descriptor. In the preceding example, three persistent fields are defined in the data accessor methods: empNumber, empName, and salary.
These fields are defined as persistent fields in the ejb-jar.xml deployment descriptor within the <cmp-field><field-name> element, as follows:
<enterprise-beans>
<entity>
<display-name>Employee</display-name>
<ejb-name>EmployeeBean</ejb-name>
<local-home>employee.EmployeeLocalHome</local-home>
<local>employee.EmployeeLocal</local>
<ejb-class>employee.EmployeeBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.Integer</prim-key-class>
<reentrant>False</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>Employee</abstract-schema-name>
<cmp-field><field-name>empNumber</field-name></cmp-field>
<cmp-field><field-name>empName</field-name></cmp-field>
<cmp-field><field-name>salary</field-name></cmp-field>
<primkey-field>empNumber</primkey-field>
</entity>
...
</enterprise-beans>
Map these fields to the database as follows:
Accept the defaults for these fields and avoid more deployment descriptor configuration. See "Configuring Default Mapping of Persistent Fields to the Database" for more information.
Map the persistent data fields to columns in a table that exists in a designated database. The persistent data mapping is configured within the orion-ejb-jar.xml file. See "Configuring Explicit Mapping of Persistent Fields to the Database" for more information.
If you simply define the persistent fields in the ejb-jar.xml file, then OC4J provides the following mappings of these fields to the database:
Database: The default database as set up in your OC4J instance configuration. For the JNDI name, use the <location> element for emulated data sources, and <ejb-location> element for nonemulated data sources.
Upon installation, the default database is a locally installed Oracle database that must be listening on port 1521 with a SID of ORCL. To customize the default database, change the first configured database to point to your database.
Table: The container automatically creates a default table where the name of the table is guaranteed to be unique. For all future redeployments, copy the generated orion-ejb-jar.xml file with this table name into the same directory as your ejb-jar.xml file. Thus, all future redeployments have the same table names as first generated. If you do not copy this file over, different table names may be generated.
The table name is constructed with the following names, where each name is separated by an underscore character ( _ ):
EJB name defined in <ejb-name> in the deployment descriptor.
JAR file name, including the .jar extension. However, all dash characters ( - ) and periods ( . ) are converted to underscore characters ( _ ) to follow SQL conventions. For example, if the name of your JAR file is employee.jar, then employee_jar is appended to the name.
Application name that you define during deployment.
If the constructed name is greater than thirty characters, the name is truncated at twenty-four characters. Then six characters made up of an alphanumeric hash code are appended to the name.
For example, if the EJB name is EmpBean, the JAR file is empl.jar, and the application name is employee, then the default table name is EmpBean_empl_jar_employee.
Column names: The columns in the entity bean table each have the same name as the <cmp-field> elements in the designated database. The data types for the database, translating Java data types to database data types, are defined in the specific database XML file, such as oracle.xml.
As "Configuring Default Mapping of Persistent Fields to the Database" discusses, your persistent data can be automatically mapped to a database table by the container. However, if the data represented by your bean is more complex or you do not want to accept the defaults that OC4J provides for you, then you can map the persistent data to an existing database table and its columns within the orion-ejb-jar.xml file. Once the fields are mapped, the container provides the persistence storage of the persistent data to the indicated table and rows.
To explicitly map persistent fields to the database, do the following:
Deploy your application with only the ejb-jar.xml elements configured.
OC4J creates an orion-ejb-jar.xml file for you with the default mappings in them. It is easier to modify than to create these fields.
Modify the <entity-deployment> element (see Table A-1, "Attributes of the <entity-deployment> Element") in the orion-ejb-jar.xml file to use the database table and columns you specify.
Once you define container-managed persistent fields, each within its own <cmp-field> element, you can map each to a specific database table and column. Thus, you can map these persistent fields to existing database tables. The mapping occurs with the orion-ejb-jar.xml file (the OC4J-specific deployment descriptor).
The explicit mapping of persistent fields is completed within an <entity-deployment> element t (see Table A-1, "Attributes of the <entity-deployment> Element"). This element contains all mapping for an entity bean. The following are the attributes and elements that are specific to persistent field mapping:
<entity-deployment name="..." location="..." table="..." data-source="...">
<primkey-mapping>
<cmp-field-mapping name="..." persistence-name="..." />
</primkey-mapping>
<cmp-field-mapping name="..." persistence-name="..." />
...
</entity-deployment>
Table 5-2 Deployment Descriptor's Elements for Mapping Persistent Fields to a Specific Database Table
| Element or Attribute Name | Description |
|---|---|
|
|
Bean name, which is defined in the |
|
|
JNDI location. |
|
|
Database table name. |
|
|
Data source for the database where the table resides. |
|
|
Definition of how the primary key is mapped to the table. |
|
|
The name attribute specifies the |
You can configure the following within the orion-ejb-jar.xml file:
Configure the <entity-deployment> element for every entity bean that contains container-managed persistent fields that you will map within it.
Configure a <cmp-field-mapping> element for every field within the bean that you are mapping. Each <cmp-field-mapping> element must contain the name of the field to be persisted, as follows:
Configure the primary key in the <primkey-mapping> element contained within its own <cmp-field-mapping> element.
Configure simple data types (such as a primitive, simple object, or serializable object) that are mapped to a single field within a single <cmp-field-mapping> element. The name and database field are fully defined within the element attributes.
Example 5-5 Mapping Persistent Fields to a Specific Database Table
Example 5-5 demonstrates how to map persistent fields in your bean instance to database tables and columns by mapping the employee persistence fields to the Oracle database table EMP:
<entity-deployment name="EmpBean" location="emp/EmpBean" wrapper="EmpHome_EntityHomeWrapper2" max-tx-retries="3" table="emp" data-source="jdbc/OracleDS"> <primkey-mapping> <cmp-field-mapping name="empNumber" persistence-name="empnumber" /> </primkey-mapping> <cmp-field-mapping name="empName" persistence-name="ename" /> <cmp-field-mapping name="salary" persistence-name="sal" /> ... </entity-deployment>
After deployment, OC4J maps the element values, as Table 5-3 shows:
A relationship field identifies a related bean. A relationship field behaves similar to a foreign key in a database table. For more information, see "Relationship Fields".
Relationship fields are virtual. You provide getters and setters for these fields in the code of your bean class, similar to the following:
public abstract void setContractInfo(ContractInfo contractInfo) throws RemoteException public abstract ContractInfo getContractInfo() throws RemoteException
The container provides the implementation of these methods.
In the preceding example, the corresponding relationship field is contractInfo.
In a deployment descriptor, this field is defined in a <cmr-field><cmr-field-name> element, as follows:
<ejb-ralation>
...
<cmr-field>
<cmr-field-name>contractInfo</cmr-field-name>
<cmr-field-type>contractInfo</cmr-field-type>
</cmr-field>
...
</ejb-ralation>
For more information about container-managed relationships, see "Container-Managed Relationships".
As each entity bean maps to a table in a database, each of its persistent and relationship fields are saved within a database table in columns. You can map these fields to the database by performing one of the following:
Accept the defaults for these fields. Do not configure the deployment descriptor. The tables are automatically created for the bean based on the information in the ejb-jar.xml file. See "Configuring Default Mapping of Relationship Fields to the Database" for more information.
Map these fields to columns in a table that already exists in a designated database. The persistent data mapping is configured within the orion-ejb-jar.xml file. See "Configuring Explicit Mapping of Relationship Fields to the Database" for more information.
When you declare relationship fields in the ejb-jar.xml file, OC4J provides default mapping of these fields to the database at the time of the automatic generation of the orion-ejb-jar.xml file. The default mapping for relationship fields is the same as for the persistent fields (see "Configuring Default Mapping of Persistent Fields to the Database").
|
Note: For all future redeployments, copy the automatically generatedorion-ejb-jar.xml file with the indicated table name into the same directory as your ejb-jar.xml file from the J2EE_Home/application-deployments directory. If you fail to do so, different table names may be generated at each redeployment. |
In summary, the default mappings include the following:
Database–The default database as set up in your OC4J instance configuration.
Default table–Each entity bean in the relationship represents data in its own underlying database table. The name of the entity bean's underlying table is supposed to be unique, so it is constructed with the following names, where each entry is separated by an underscore character ( _ ):
EJB name defined in a <ejb-name> element in the deployment descriptor;
JAR file name, including the.jar extension. However, all dash characters ( - ) and periods ( . ) are converted to underscore characters ( _ ) to follow SQL conventions. For example, if the name of your JAR file is address.jar, then address_jar is appended to the name;
Application name as defined by you during the deployment.
If the constructed name is greater than 30 (thirty) characters, the name is truncated at 24 (twenty-four) characters. An underscore character ( _ ), and then 5 (five) characters made up of an alpha-numeric hash code are appended to the name for uniqueness.
For example, if the EJB name is AddressEntry, the JAR file name is addr.jar and the application name is address, then the default table name would be AddressEntry_addr_jar_address.
Column names in each table–The container generates columns in each table based on the <cmp-field> and <cmr-field> elements defined in the deployment descriptor. A column is created for each <cmp-field> element that relates to the entity bean data. In addition, a column is created for each <cmr-field> element that represents a relationship. In a unidirectional relationship (see "Direction in CMR"), only a single entity in the relationship defines a <cmr-field> in the deployment descriptor. In bidirectional relationship (see "Direction in CMR"), both entities in the relationship define a <cmr-field>.
For each <cmr-field> element, the container creates a foreign key that points to the primary key of the relevant object, as follows:
In the default one-to-one relationship, the foreign key is created in the database table for the source entity bean, and is directed to the primary key of the target database table. For example, if one employee has one address, then the foreign key is created within the employee table that points to the primary key of the address table.
The default for one-to-many relationship uses a foreign key.
The default for many-to-many relationships creates an association table (a third table). This association table contains two foreign keys, where each key points to the primary key of one of the entity tables.
Since the <cmp-field> and <cmr-field> elements represent Java data types, they may not convert to database types in the manner you believe they should. There is a set of rules for converting CMP types to database types that you must follow (see "Conversion of CMP Types to Database Types"). Note that you can modify the translation rules of converting Java data types to database data types in special database XML files that are located in J2EE_HOME/config/database-schemas directory. This directory includes all database files. The Oracle Database conversion file is named oracle.xml.
Primary keys–Entity beans' underlying tables contain primary keys (see "Configuring Primary Key"). The following are the types of primary keys:
Defined primary key: The primary key is generated as designated in the <primkey-field> element as a simple data type or class. Thus, the column name is the same as the name in the <primkey-field> element.
Composite primary key: The primary key is defined within a class, and is composed of several fields. Each field within the composite primary key is represented by a column in the database table, where each field is considered part of the primary key in the table.
Automatically generated primary key: If you specify a java.lang.Object as the primary key class type in <prim-key-class> element, but do not specify the primary key name in <primkey-field> element, then the primary key is automatically generated the the container. The column is named AUTOID.
In defining the container-managed persistent fields in the <cmp-field> and the primary key types, you can define simple data types and Java classes that are serializable.
This section contains information on the following:
Table 5-4 provides a list of the supported simple data types, which you can provide in the persistence-type attribute, with the mapping of these types to SQL types and to Oracle database types. Note that none of these mappings are guaranteed to work on non-Oracle databases.
Table 5-4 Simple Data Types
| Known Type (native) | SQL Type | Oracle Type |
|---|---|---|
|
java.lang.String |
VARCHAR(255) |
VARCHAR(255) |
|
java.lang.Integer[] |
INTEGER |
NUMBER(20,0) |
|
java.lang.Long[] |
INTEGER |
NUMBER(20,0) |
|
java.lang.Short[] |
INTEGER |
NUMBER(10,0) |
|
java.lang.Double[] |
DOUBLE PRECISION |
NUMBER(30,0) |
|
java.lang.Float[] |
FLOAT |
NUMBER(20,5) |
|
java.lang.Byte[] |
SMALLINT |
NUMBER(10,0) |
|
java.lang.Character[] |
CHAR |
CHAR(1 |
|
java.lang.Boolean[] |
BIT |
NUMBER(1,0) |
|
java.util.Date |
DATETIME |
DATE |
|
java.sql.Date |
DATE |
DATE |
|
java.uti.Time |
DATE |
DATE |
|
java.sql.Timestamp |
TIMESTAMP |
TIMESTAMP |
|
java.lang.String |
CLOB |
CLOB |
|
char[] |
CLOB |
CLOB |
|
byte[] |
BLOB |
BLOB |
|
java.io.Serializable (4KB limit) |
LONGVARBINARY |
BLOB |
|
Note: You can modify the mapping of these data types in theconfig/database-schema/<db>.xml configuration files. |
The Date and Time map to DATE in the database, because the DATE contains the time. The Timestamp, however, maps to TIMESTAMP in the database, which gives the time in nanoseconds.
Mapping java.sql.CLOB and java.sql.BLOB directly is not currently supported because these objects are not serializable. However you can map a String or char[] and byte[] to database column type CLOB and BLOB respectively. Mapping a char[] to a CLOB or a byte[] to a BLOB can only be done with an Oracle database. The Oracle JDBC API was modified to handle this operation.
There is a 4 KB limit when mapping a serialized object to a BLOB type over the JDBC Thin driver.
When String and char[] variables map to a VARCHAR2 in the database, it can only hold up to 2K. However, you can map String object or char[] larger than 2K to a CLOB by doing the following:
The bean implementation uses the String or char[] objects.
The persistence-type attribute of the <cmp-field-mapping> element defines the object as a CLOB, as follows:
<cmp-field-mapping name="stringdata" persistence-name="stringdata"
persistence-type="CLOB" />
Similarly, you can map a byte[] in the bean implementation to a BLOB, as follows:
<cmp-field-mapping name="bytedata" persistence-name="bytedata"
persistence-type="BLOB" />
In addition to simple data types, you can define user classes that implement java.io.Serializable interface. These classes are stored in a BLOB in the database.
You should not define other entity beans or Collection objects as a CMP type–these are relationships and should be defined within a relationship field, as follows:
A relationship to another entity bean is always defined in a <cmr-field> relationship.
Collection objects promote a "many" side of a relationship and should be configured within a <cmr-field> relationship.
|
Note: You should not use subinterfaces ofCollection (such as List, for example). Use the Collection instead. |
As "Configuring Default Mapping of Persistent Fields to the Database" discusses, the container can automatically map your relationship fields to the database tables. If you do not want to accept the defaults that OC4J provides for you, or if you need to map the fields to an existing database table, then you can manually map the relationships between entity beans to an existing database table and its columns in the orion-ejb-jar.xml file.
|
Note: You need to modify elements and attributes of the<entity-deployment> element t (see Table A-1, "Attributes of the <entity-deployment> Element") in the orion-ejb-jar.xml file to explicitly map relationship fields. JDeveloper IDE is capable of managing complex mappings between the entity beans and the database tables. Thus, JDeveloper validates the deployment descriptors and prevents inconsistencies. You can modify the orion-ejb-jar.xml file on your own; however, Oracle suggests that you use JDeveloper for modifying container-managed relationships. For more information about JDeveloper, see "Using JDeveloper". |
To manually match an existing database to the entity bean's mappings, modify the orion-ejb-jar.xml file by following this procedure:
Deploy your entity bean with container-managed persistence with the <autocreate-tables> element set to false in the orion-application.xml file.
Copy the orion-ejb-jar.xml file from the application-deployments/ directory to your development directory.
Modify the <data-source> element to point to the correct data source. Note that all beans that are associated with each other must use the same data source.
Modify the table attribute to point to the correct table. Make sure that it is the correct table for the bean that is defined in the <entity-deployments> element.
Modify the persistence-name attributes to point to the correct column for each bean's persistence type, whether a persistent or relationship field.
Set the <autocreate-tables> element in orion-application.xml file to true.
Rearchive and redeploy your application.
To manually modify mapping elements if there is no existing database to match to your entity bean's mappings, follow this procedure:
Deploy your bean with the <autocreate-tables> element set to false in the orion-application.xml file and the ejb-jar.xml elements configured.
OC4J creates an orion-ejb-jar.xml file with the default mappings in it. It is easier to modify these fields than to create them.
Copy the container-created orion-ejb-jar.xml file from the J2EE_HOME/application-deployments directory to your development environment.
Modify the <entity-deployment> element (see Table A-1, "Attributes of the <entity-deployment> Element") in the orion-ejb-jar.xml file to use the database table and columns that you specify based on the relationship type. For more information, see"Configuring orion-ejb-jar.xml to Map Bean Relationships to Database Tables".
Set the <autocreate-tables> element in orion-application.xml file to true.
Rearchive and redeploy your application.
|
Note: If you deploy your application without setting<autocreate-tables> to false, then OC4J automatically creates the default tables. You must delete all these tables before redeploying the application. You must also delete an association table, if any. |
The relationship between the entity beans is defined in the <relationships> element in the ejb-jar.xml file. The mapping between the entity bean and the database table and columns is specified in the <entity-deployment> element in the orion-ejb-jar.xml file.
The orion-ejb-jar.xml file maps the bean relationships to database table and columns within a <cmp-field-mapping> element. The following is the XML structure of the <entity-deployment> and <cmp-field-mapping> elements for a simple one-to-one relationship:
<entity-deployment name="SourceBeanName" location="JNDIlocation" table="TableName" data-source="DataSourceJNDIName"> ... <cmp-field-mapping name="CMRfield_name"> <entity-ref home="targetBeanName"> <cmp-field-mapping name="CMRfield_name" persistence-name="targetBean_PKcolumn" /> </entity-ref> </cmp-field-mapping> ...
Within the <cmp-field-mapping> element, you can define the bean's name (the source of the relationship that indicates the direction), the JNDI location, the database table to which the information is persisted, and map each of the persistent and relationship fields defined in the ejb-jar.xml file to the underlying database.
The attributes of the <entity-deployment> element (see Table A-1, "Attributes of the <entity-deployment> Element") define the following for the bean:
The name attribute identifies the EJB name of the bean, which was defined in the <ejb-name> element in the ejb-jar.xml file. This name attribute connects the ejb-jar.xml file definition for the bean to its mapping to the database.
The location attribute identities the JNDI name of the bean.
The table attribute identifies the database table to which this entity bean is mapped.
The data-source attribute identifies the database in which the table resides. The data source must be the same for all beans that interact with each other or are associated with each other. This includes beans that are in the same application, part of the same transaction, or beans that are in a parent-child relationship.
The <cmp-field-mapping> element in the orion-ejb-jar.xml file maps the following fields to database columns:
The <cmp-field> element in the ejb-jar.xml file defines a persistent field.
The <cmr-field> element in the ejb-jar.xml file defines a relationship field.
Example 5-6 ejb-jar.xml and orion-ejb-jar.xml Mapping for a One-To-One Relationship
Example 5-6 demonstrates how the <cmr-field> element in the ejb-jar.xml file maps to the <cmp-field-mapping> element in the orion-ejb-jar.xml file. The name attribute in the <cmp-field-mapping> provides the link between the two XML files. You must not modify any name attributes.
EJB-JAR.XML
<relationship-role-source>
<ejb-name>EmpBean</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>address</cmr-field-name>
</cmr-field>
ORION-EJB-JAR.XML
<cmp-field-mapping name="address"> <entity-ref home="AddressBean"> <cmp-field-mapping name="address" persistence-name="addressPK" /> </entity-ref> </cmp-field-mapping>
To fully identify and map relationship fields, nested <cmp-field-mapping> elements are used. The format of the nesting depends on the type of relationship. The database column that is the primary key of the target bean is defined in the persistence-name attribute of the internal <cmp-field-mapping> element. If you have an existing database, you would be modifying the persistence-name attributes for each <cmp-field-mapping> element to match your column names.
In a hypothetical model, there is a one-to-one unidirectional relationship (see "Direction in CMR") between a single employee (represented by EmpBean) and his/her address (represented by AddressBean). The EmpBean points to the AddressBean using the relationship field address. These two beans will map to the EMP and ADDRESS database tables. The EMP table has a foreign key named address, which points to the primary key of the ADDRESS table named AddressPK.
Example 5-7 Explicit One-to-One Unidirectional Relationship Mapping
The beans and their relationships are specified in both the ejb-jar.xml and the orion-ejb-jar.xml deployment descriptors. As Example 5-7 shows, in the ejb-jar.xml file, the one-to-one relationship between the EmpBean and AddressBean is defined within a <relationships> element. The direction (see "Direction in CMR") is designated by one or two <cmr-field> elements.
The mapping of the beans to their database persistent storage is defined in the orion-ejb-jar.xml file. The one-to-one relationship is mapped on both sides with an <entity-ref> element inside a <cmp-field-mapping> element. The <entity-ref> describes the target entity bean of the relationship.
EJB-JAR.XML
<relationships>
...
<ejb-relation>
...
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>EmpBean</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>address</cmr-field-name>
</cmr-field>
...
</ejb-relation>
<ejb-relation>
...
<relationship-role-source>
<ejb-name>AddressBean</ejb-name>
</relationship-role-source>
...
</ejb-relation>
...
ORION-EJB-JAR.XML
<entity-deployment name="EmpBean"...
<cmp-field-mapping name="address">
<entity-ref home="AddressBean">
<cmp-field-mapping name="address" persistentce-name="addressPK" />
</entity-ref>
</cmp-field-mapping>
...
</entity-deployment>
<entity-deployment name="AddressBean"...
...
<cmp-field-mapping name="empNumber">
<entity-ref home="EmpBean">
<cmp-field-mapping name="empNumber" persistentce-name="empnumber" />
</entity-ref>
</cmp-field-mapping>
...
</entity-deployment>
To map your bean fields to an existing database, you need to understand the fields within the <cmp-field-mapping> element in the orion-ejb-jar.xml file. This element has the following structure:
<cmp-field-mapping name="CMRField_name"> <entity-ref home="targetBeanName"> <cmp-field-mapping name="CMRfield_name" persistence-name="targetBean_PKcolumn" /> </entity-ref> </cmp-field-mapping>
In the preceding structure example, the following occurs:
The name attribute of the <cmp-field-mapping> element is the same as the <cmp-field> element in the ejb-jar.xml file. Do not modify the name attribute in the <cmp-field-mapping> element.
The target bean name is specified in the home attribute of the <entity-ref> element.
The database column that is the primary key of the target bean is defined in the persistence-name attribute of the internal <cmp-field-mapping> element. If you have an existing database, modify the persistence-name attributes for each <cmp-field-mapping> element to match your column names.
In a hypothetical model, each employee (represented by EmpBean) belongs to only one department (represented by DeptBean), and each department can contain multiple employees. The department table has a primary key. The employee table has a primary key to identify each employee and a foreign key to point back to the employee's department. If you want to find the department for a single employee, a simple SQL statement retrieves the department information from the foreign key. To find all employees in a department, the container executes a JOIN statement on both the department and employee tables and retrieves all employees with the designated department number.
This is the default behavior. If you need to change the mappings to other database tables, then use either JDeveloper, or manually modify the orion-ejb-jar.xml file to manipulate the <collection-mapping> or <set-mapping> element.
|
Note: Modify elements and attributes of the<entity-deployment> element (see Table A-1, "Attributes of the <entity-deployment> Element") in the orion-ejb-jar.xml file to explicitly map relationship fields. JDeveloper is capable of managing the complex mapping between the entity beans and the database tables. JDeveloper validates the deployment descriptors and prevents inconsistencies. Even though you can modify the orion-ejb-jar.xml file on your own, Oracle suggests you to use JDeveloper for modifying container-managed relationships. For more information about JDeveloper, see "Using JDeveloper". |
Example 5-8 Explicit One-to-Many Bidirectional Relationship Mapping Using Foreign Key
Example 5-8 shows the mapping for the bidirectional relationship of one department with many employees. The "one" side of the relationship is the department; the "many" side of the relationship is the employee. Example 5-8 demonstrates how to manually modify the orion-ejb-jar.xml file for this relationship to use a foreign key.
EJB-JAR.XML
<relationships>
<ejb-relation>
<ejb-relation-name>Dept-Emps</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>Dept-has-Emps</ejb-relationship-role-name>
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>DeptBean</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>employees</cmr-field-name>
<cmr-field-type>java.util.Set</cmr-field-type>
</cmr-field>
</ejb-relationship-role>
<ejb-relationship-role-name>Emps-have-Dept</ejb-relationship-role-name>
<multiplicity>Many</multiplicity>
<cascade-delete/>
<relationship-role-source>
<ejb-name>EmpBean</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>dept</cmr-field-name>
</cmr-field>
</ejb-relationship-role>
</ejb-relation>
</relationships>
ORION-EJB-JAR.XML
<enterprise-beans>
<entity-deployment name="DeptBean" data-source="jdbc/scottDS" table="DEPT">
<primkey-mapping>
<cmp-field-mapping name="deptno" persistence-name="DEPTNO" /> /*PK*/
</primkey-mapping>
<cmp-field-mapping name="dname" persistence-name="DNAME" />
<cmp-field-mapping name="employees">
/*points from DEPTNO column in EMP to DEPTNO in DEPT*/
1. <collection-mapping table="EMP"> /*table with FK*/
<primkey-mapping>
<cmp-field-mapping name="DeptBean_deptno"> /*CMR field name*/
<entity-ref home="DeptBean"> /*points to DeptBean*/
2. <cmp-field-mapping name="DeptBean_deptno"
persistence-name="EDEPTNO"/>
</entity-ref>
</cmp-field-mapping>
</primkey-mapping>
<value-mapping type="mypackage1.EmpLocal">
<cmp-field-mapping name="EmpBean_empnumber">
<entity-ref home="EmpBean">
<cmp-field-mapping name="EmpBean_empnumber"
persistence-name="EMPNUMBER"/>
</entity-ref>
</cmp-field-mapping>
</value-mapping>
</collection-mapping>
</cmp-field-mapping>
</entity-deployment>
<entity-deployment name="EmpBean" data-source="jdbc/scottDS" table="EMP">
<primkey-mapping>
<cmp-field-mapping name="empNumber" persistence-name="EMPNUMBER"/>
</primkey-mapping>
<cmp-field-mapping name="empName" persistence-name="ENAME" />
<cmp-field-mapping name="salary" persistence-name="SAL" />
<cmp-field-mapping name="dept"> /*foreign key*/
<entity-ref home="DeptBean">
2. <cmp-field-mapping name="dept" persistence-name="EDEPTNO" />
</entity-ref>
</cmp-field-mapping>
</entity-deployment>
</enterprise-beans>
In the preceding orion-ejb-jar.xml example, if the table identified in the <collection-mapping> or <set-mapping> element of the "one" relationship (the department) is the name of the target bean's table (the employee bean table), then the one-to-many relationship is defined with a foreign key. For example, the table attribute in the department definition is EMP.
The foreign key is defined in the database table of the "many" relationship. In the preceding example, the EDEPTNO foreign key column exists in the EMP database table. This is defined in a persistence-name attribute of the <cmp-field-mapping> element in the EmpBean configuration.
Thus, to manipulate the <collection-mapping> or <set-mapping> element in the orion-ejb-jar.xml file, modify the <entity-deployment> element (see Table A-1, "Attributes of the <entity-deployment> Element") for the "one" entity bean (which contains the Collection), as follows:
Modify the table in the <collection-mapping> or <set-mapping> table attribute in the "one" relationship to be the database table of the "many" relationship. In this example, you would modify this attribute to be the EMP table.
Modify the foreign key that points to the "one" relationship within the "many" relationship configuration. In this example, modify the <cmp-field-mapping> element to specify the EDEPTNO foreign key in the persistence-name attribute.
You can configure one of the database isolation levels (see "Entity Bean Database Isolation Levels and Resource Contention") for a specific bean. That is, you can specify that when the bean starts a transaction, the database isolation level for this bean be what is specified in the OC4J-specific deployment descriptor (on parallel execution or data consistency).
|
Note: Once set, the isolation level for the bean is valid for the entire transaction. |
You can set the isolation level for each entity bean in the isolation attribute of the <entity-deployment> element (see Table A-1, "Attributes of the <entity-deployment> Element"). You can use committed or serializable value with committed being the default. To change this default value to serializable, configure the following in the orion-ejb-jar.xml for the intended bean:
<entity-deployment ... isolation="serializable" ... </entity-deployment>
The serializable isolation level provides data consistency; the committed isolation level enables the parallel execution.
|
WARNING: Do not set the isolation level to |
|
WARNING: There is a danger of lost updates with the |
If you do not define an isolation level, you receive the level that is configured in the database. Setting the isolation level within the OC4J-specific deployment descriptor temporarily overrides the database configured isolation level for the life of the global transaction for this bean. That is, if you define the bean to use the serializable level, then OC4J will force the database to be serializable for this bean only until the end of the transaction.
You can specify both the entity bean concurrency mode and database isolation level, if the combination affects the outcome of your resource contention. See "Combining Entity Bean Database Isolation Level and Concurrency Mode" for more information.
For more information about resource contention, see "Avoiding Database Resource Contention".
The concurrency modes determine when to block to manage resource contention, or when to execute in parallel. For more information, see "Entity Bean Concurrency Modes and Resource Contention".
To set the entity bean with container-managed persistence's concurrency mode, add the appropriate concurrency value of pessimistic, optimistic, or read-only to the locking-mode attribute of the <entity-deployment> element (see Table A-1, "Attributes of the <entity-deployment> Element") in the OC4J-specific deployment descriptor (orion-ejb-jar.xml file). The default concurrency mode is optimistic. To change the concurrency mode to pessimistic, perform the following modifications:
<entity-deployment ... locking-mode="pessimistic" ... </entity-deployment>
The concurrency modes are defined on a per-bean basis and the effects of locking apply on the transaction boundaries.
Parallel execution requires the correct setting of the pool size for wrapper and bean instances.
For more information, see the following:
The exclusive-write-access attribute of the <entity-deployment> element (see Table A-1, "Attributes of the <entity-deployment> Element") states that this is the only entity bean that accesses its table in the database and that no external methods are used to update the resource. It informs the OC4J instance that any cache maintained for this bean will only be dirtied by this bean. Essentially, if you set this attribute to true, you are assuring the container that this is the only bean that will update the tables used within this bean. Thus, any cache maintained for the bean does not need to constantly update from the back-end database.
This flag does not prevent you from updating the table; that is, it does not actually lock the table. However, if you update the table manually or from another bean, the results are not automatically updated within this bean.
The default value of the exclusive-write-access attribute is false. Because of the effects of the entity bean concurrency modes (see "Configuring Concurrency Modes"), you can only set this element to true for a read-only entity bean. OC4J always resets this attribute to false for pessimistic and optimistic concurrency modes.
For more information, see the following:
In your entity bean class (see "Implementing the Entity Bean Class"), you have to provide the following configurations of the entity bean's callback methods (see "Callback Methods"):
Provide the ejbCreate method with parameters matching the associated create method defined in the home interface (see "Implementing the Entity Bean Home Interface"). See the implementation of this method in the Example 4-3, "Implementing the Entity Bean Class".
Set the primary key (see "Configuring Primary Key") in the ejbCreate method. See the implementation of this method in the Example 4-3, "Implementing the Entity Bean Class"
Define the primary key relationships, if any, in the ejbCreate method. See the implementation of this method in the Example 4-3, "Implementing the Entity Bean Class".
Define the javax.ejb.EntityContext for your bean in the setEntityContext method (see the implementation of this method in the Example 4-3, "Implementing the Entity Bean Class"). You can also allocate any other resources that will exist for the lifetime of the bean within this method.
Unset (set to null) the bean's associated entity context in the setEntityContext method. Release other resources, if any, in the setEntityContext method. See the implementation of this method in the Example 4-3, "Implementing the Entity Bean Class").
The rest of the callback methods only require an empty implementation in the entity bean class–the container provides the full implementation for these methods. However, depending on the logic of your entity bean implementation, you may take actions similar to the following:
Define the foreign key (see "Configuring Foreign Key in a Composite Primary Key") in the ejbPostCreate method.
Retrieve resources in the ejbActivate method and release them in the ejbPassivate method.
