 |
 |
 |
 |
|
|
 |
The following are the configuration parameters are available for EJB Servers in Pramati Server:
Note: Click here to read how to configure EJB Server using the Console.
In the Enterprise Bean’s life cycle, the bean instance would be in one of the following states: does not exist, pooled or associated with identity, and state. Maximum pool size for an Enterprise bean indicates the number of bean instances used by all the requests made to the bean at any particular instance of time. Requests that demand instances more than the pool size have to wait for a bean instance.
Bean pool sizes can be configured at the time of deployment in pramati-j2ee-server.xml for each bean. If the pool sizes are not specified in the deployment descriptors, default values are taken from the EJB Container configuration file, - the ejb-config.xml - that is present under the node’s configuration directory.
Bean instances are pooled to save the bean instance creation time during invocation. However, object creation time has been improved a lot in the recent Java Virtual machines. Pooling can be enabled or disabled through the configuration options provided in ejb-config.xml or pramati-j2ee-server.xml.
Free pool can be enabled at the Container level for different types of Enterprise beans through the following tags defined in the ejb-config.xml:
<bean-pool-config>
<default-entity-min-pool-size>1000</default-entity-min-pool-size>
<default-entity-max-pool-size>10000</default-entity-max-pool-size>
<default-session-min-pool-size>1000</default-session-min-pool-size>
<default-session-max-pool-size>10000</default-session-max-pool-size>
<default-mdb-min-pool-size>1000</default-mdb-min-pool-size>
<default-mdb-max-pool-size>10000</default-mdb-max-pool-size>
<default-low-activity-interval-minutes>60</default-low-activity-interval-minutes>
<enable-freepool-for-stateless>true</enable-freepool-for-stateless>
<enable-freepool-for-bmp>false</enable-freepool-for-bmp>
<enable-freepool-for-cmp>true</enable-freepool-for-cmp>
<pool-waittimeout-millis>60000</pool-waittimeout-millis>
</bean-pool-config>
Note: Stateful session bean instances cannot be re-used unlike the other types of beans as there is no way for the container to reset its state. Hence, there is no free pool for Stateful session beans.
Free pool can be enabled at the bean level in pramati-j2ee-server.xml with the enable-freepool tag. If none is specified, it assumes the behavior specified at the container level.
When the bean instance is associated with an identity and state, the bean is said to be in ready state. This bean instance can be readily used for method invocation.
When the stateful session beans are created, they are in ready state until they are either passivated or removed. All the ready stateful session bean instances are cached in memory for subsequent requests. The maximum number of instances that can be cached is same as the max pool size specified for this bean. When the limit reaches, an LRU-based victimization policy is used to passivate the instances to a persistent store.
The Container automatically caches entity bean instances across transactions when the bean is deployed with the Exclusive DB access exclusion-type. If bean instance pooling is also enabled for these entity beans, the pool size is shared by free bean instances and the cached instances.
Enterprise bean invocation requires resources such as bean instances, threads, locks etc. When the container is unable to provide the required resources, the requests would wait for the resources. To avoid unbounded resource waits, timeouts are specified through configuration. If the requests wait for more than the specified timeout period, EJB container throws an exception indicating a timed-out request.
Pool timeout indicates the maximum time a client would wait to get a bean instance. All EJB 2.1 beans use this. This timeout can be configured at bean level using pool-waittimeout-millis tag under the ejb tag in pramati-j2ee-server.xml.
This can also be specified as a property pool-waittimeout-millis at the EJB Container service level in the server-config.xml. Default value is 60,000 milliseconds.
Primary Key wait timeout indicates the maximum time a bean would wait for a particular Primary Key. This timeout is specified only for Entity Beans.
This timeout can be configured at bean level using pk-waittimeout-millis tag under the ejb tag in pramati-j2ee-server.xml. This can also be configured using the pk-waittimeout-millis tag present under the bean-locking-options tag in ejb-config.xml. Default value is 30,000 milliseconds.
Session timeout indicates the maximum time a stateful session can exist within the container, available for client requests. When a client makes a request on a stateful session that has timed out, Container throws an exception and discards the session.
This timeout value can be configured at the bean level using session-timeout tag under the ejb tag in pramati-j2ee-server.xml. This can also be specified using the default-session-timeout-minutes tag in the ejb-config.xml. Default value is 120 minutes.
BMP Entity beans can be configured to perform pessimistic or optimistic locking. By default the container locks the BMP bean instance for the duration of the transaction. While using the No lock option, the container creates multiple bean instances for the same PK to allow concurrent access and it is the responsibility of the bean provider to take care of locking.
BMP Locking and caching can be configured at EJB Container service level, or at module or bean level.
To configure at EJB Container service, add lock-bmp tag in the ejb-config.xml. By default, the container uses pessimistic locking for BMP.
To configure at module level, add the lock-bmp tag under ejb-module tag in pramati-j2ee-server.xml. Following are the permitted values for the lock-bmp tag:
To configure at bean level, add the lock-bmp tag under the corresponding ejb tag in pramati-j2ee-server.xml.
EJB Container locks the stateless session bean instances during request processing. It can choose one of the following mechanisms for locking the bean instances:
slsb-locking tag at the EJB service level (in the ejb-config.xml) as well as at the bean level (that is, in the pramati-j2ee-server.xml)
When a CMP bean is deployed with Read Only isolation level, the container caches the entity bean state. If there were any updates directly to the underlying persistent store, the cached container's state would become stale. By configuring refresh interval the container is instructed to update its cached state after a specified interval of time.
This is configured through ro-refreshinterval-millis tag under ejb in pramati-or-map.xml at the bean level and also through the ro-refreshinterval-millis tag in the ejb-config.xml.
In the case of CMP beans deployed with Optimistic Repeatable Read isolation level and with exclusive DB access, at the end of the transaction, verified update query is executed to check the state/version of the DB and complete the update. When there are no updates to the bean in a transaction, a simple query to check the existence of the row with the same state as that of the current entity is executed. Applications may configure to disable this query to achieve optimization when there are less concurrent updates (hypothetical situation).
This is configured through orr-row-exists-check tag under ejb in pramati-or-map.xml at the bean level and also through the orr-row-exists-check tag in the ejb-config.xml. This option is enabled by default.
When a CMP bean is deployed with Optimistic Repeatable Read isolation level and with exclusive DB access, the container caches the bean’s state with the optimism that there are no updates to the persistent store externally. If the state in the cache becomes stale, the transaction would rollback, as the state is verified with that of the persistent store during commit.
By enabling this option, the container ensures that it does not read stale data during the transaction begin and hence reduces the probability of rollback. This is supposed to be enabled when the cost of rollback is high and no load optimization is required.
This is configured through load-at-tx-begin tag under ejb in pramati-or-map.xml at the bean level and also through the load-at-tx-begin tag in the ejb-config.xml. By default this option is disabled.
For applications that slightly deviate from the behavior proposed by the specification, leniency is required. Following are the cases of leniency frequently seen in the applications to gain performance or application development ease. Specification leniency can be explicitly configured through the strict-compliance tag in the ejb-config.xml. By default this property is set as false.
Pass by reference semantics, when compared to the usual pass-by-value semantics enforced by the RMI or EJB specification, yield performance, as the cloning or serialization costs are not involved.This can be configured through the pass-by-reference tag in the ejb-config.xml. By default pass-by-reference is enabled.
EJB specification does not allow removal of stateful session bean within a transaction. This becomes painful when the application wants to perform cleanup of the session at the end of the transaction. This can be configured through the sfsb-allow-transactional-remove tag in the ejb-config.xml. By default sfsb-allow-transactional-remove is enabled.
If the property strict-compliance is set to true, pass-by-reference and sfsb-allow-transactional-remove are automatically set to false or disabled.
Related Topics:
 |
|
| © Pramati Technologies 2007 | Runs on Pramati Server | Feedback | Legal |