9.10.3 Setting the runtime properties for Entity Beans
You set the application runtime properties for the individual Entity Beans that form an application.
- Organization of this subsection
(1) Attribute file to be edited
Entity Bean attribute file
(2) Acquiring the attribute file to be edited and setting the attributes
-
Acquiring the attribute file
Execute the following command to acquire an Entity Bean attribute file:
- Execution format
cjgetappprop [server-name] [-nameserver provider-URL] -name J2EE application-name -type ejb -resname EJB-JAR-display-name/Entity-Bean-display-name -c path-of-the-Entity-Bean-attribute-file
- Example of execution
cjgetappprop MyServer -name account -type ejb -resname account/MyAccount -c C:\home\MyAccount.xml
-
Setting the attributes
Execute the following command to apply the values of the Entity Bean attribute file:
- Execution format
cjsetappprop [server-name] [-nameserver provider-URL] -name J2EE application-name -type ejb -resname EJB-JAR-display-name/Entity-Bean-display-name -c path-of-the-Entity-attribute-file
- Example of execution
cjsetappprop MyServer -name account -type ejb -resname account/MyAccount -c C:\home\MyAccount.xml
(3) Attribute settings to be edited
The following table describes the property settings for the runtime attributes of Entity Bean (<runtime>):
|
Items |
Mandatory |
Corresponding tags |
|---|---|---|
|
Look up name of the Enterprise Bean#1 |
Y |
<lookup-name> |
|
Optional name of the Enterprise Bean name having a remote interface#1 |
O |
<optional-name> |
|
Optional name of the Enterprise Bean name having a local interface#1 |
O |
<local-optional-name> |
|
Maximum number of sessions#2 |
O |
<maximum-instances> |
|
Pass by reference settings#3 |
O |
<pass-by-reference> |
|
Maximum number of the instances in the pool |
Y |
<pooled-instance> - <maximum> |
|
Minimum number of the instances in the pool |
Y |
<pooled-instance> - <minimum> |
|
Data caching method |
Y |
<caching-model> |
|
Existence period of EJB object |
O |
<entity-timeout> |
- Legend:
-
Y: Mandatory
O: Optional
- #1
-
For referencing and changing the name registered in the JNDI namespace, see 9.13.2 Referencing and changing the Enterprise Bean name.
- #2
-
The maximum number of sessions specified in the Entity Bean is the maximum number of Entity Beans that can be used from the EJB client application. If '0' is specified, the number of remote objects of the Entity Bean that can be generated concurrently becomes infinite (the real maximum value is 2147483647).
- #3
-
The pass by reference settings can also be specified in the usrconf.properties file. If the settings are specified in either the properties or in the usrconf.properties file, pass by reference settings become valid.
For details on the property settings, see 3.5.1 Specifications of the HITACHI Entity Bean Property file in the uCosminexus Application Server Application and Resource Definition Reference Guide.
The property settings and operations are explained below:
- Maximum number of instances in the pool
-
The Entity Beans pooled in the memory have the following two states:
-
ready state
An Entity Bean in a ready state indicates a bean in a state where the data is read from the database during an instance and has an identity as an Entity Bean. The beans in the ready state are already executable when accessed from the EJB client application.
-
pool state
An Entity Bean in a pool state indicates a bean in a state where the data is not read from the database during an instance and does not have an identity as an Entity Bean. Once the beans in the pool state are activated to a ready state, the beans can be executed.
If there are several Entity Beans in the ready state, some of these Entity Beans are passivated to the pool state. At this time, however, among the Entity Beans in the ready state, the beans that are in transaction are not passivated.
Specify the maximum number of pooled Entity Beans that are in the ready state and pool state, in the maximum number (<pooled-instance> - <maximum>) of the instances in the pool. This is the upper limit of the Entity Bean instances deployed on the memory.
If '0' is specified in the maximum number of instances in the pool, the number of pooled Entity Bean instances becomes infinite.
If the number of pooled instances exceeds the maximum number of instances in the pool, J2EE server passivates the instances that are least activated.
-
- Minimum number of instances in the pool
-
Specify the minimum number of pooled Entity Beans that are in the ready state and pool state. This value is the lower limit of the Entity Bean instances deployed on the memory. The number of Entity Beans specified here is generated when the J2EE application starts. These Entity Beans are converted to the pool state or the ready state and are then pooled. The number of pooled Entity Beans lies between the maximum and the minimum count, depending on the volume of access from the EJB client applications.
If '0' is specified in the minimum number (<pooled-instance> - <minimum>) of instances in the pool, the Entity Bean is not generated when the J2EE application starts. Specify the minimal memory size in which the Entity Bean instances, not referenced by the client, are to be stored. This value must not exceed the maximum number of instances in the pool (<pooled-instance> - <maximum>).
- Data caching method
-
Specify the cache model (commit option) of the Entity Bean.
-
Full caching (commit option A)
When the transaction starts, the data from the database is not read in the Entity Bean instance; therefore, the transaction is started with the Entity Bean in the same state as when the transaction was committed previously (For example, if another J2EE server updates the Entity Bean between the previous commit transaction and the start of the transaction, the consistency in the Entity Bean state is not maintained). Full caching is a cache model for the reference node Entity Bean.
-
Caching (commit cache option B)
When the transaction starts, the data from the database is read in the Entity Bean instance; therefore, the transaction is started with the Entity Bean in the same state as the latest state of the database. Caching is a cache model for the update node Entity Bean.
-
No caching (commit cache option C)
The Entity Bean is passivated when the transaction is committed. When the transaction starts, the Entity Bean is activated once and the data from the database is read in the Entity Bean instance. The transaction is, therefore, started with the Entity Bean in the same state as the latest state of the database. No caching is a cache model for the update node Entity Bean. Furthermore, since these Entity Beans are definitely passivated upon transaction commit, this cache model suits the case where you use several Entity Beans.
-
- Existence period of the EJB object
-
Specify the timeout value in seconds. Specify the value as 0 or as a positive integer. At the minimum, the EJB object of the passivated Entity Bean exists for the time period specified in this timeout value. At the maximum, the EJB object of the passivated Entity Bean only exists for the time period specified in this timeout value + the time specified in ejbserver.container.passivate.scan.interval of the usrconf.properties file. If the client does not access the EJB object even after the timeout period elapses, the applicable EJB object is deleted.
If '0' is specified in the existence period of the EJB object (<entity-timeout>), timeout does not occur.
(4) Notes
-
If an upper limit is specified for the maximum number of EJB objects of the Entity Bean that can be generated concurrently, an upper limit must also be specified for the maximum number of pooled Entity Beans.
-
Specify the maximum number of EJB objects of the Entity Beans that can be generated concurrently, the maximum number of pooled Entity Beans and the minimum number of pooled Entity Beans such that the following conditions are fulfilled:
Minimum number of pooled Entity Beans ≤ Maximum number of pooled Entity Beans ≤ Maximum number of EJB objects of the Entity Beans that can be generated concurrently