CMP bean associated technologies
WAS delivers container-managed persistence (CMP) services beyond the standards set by the EJB specification.
According to the specification, the EJB container synchronizes the state of CMP beans with the underlying database, and manages the relationships (container-managed relationships, or CMR's) among entity beans. Thus the EJB specification relieves bean developers from writing any database-specific code; instead, they can focus on writing business logic. WAS offers the following additional CMP functions to increase development efficiency even more, as well as optimize the run-time performance of business logic:
- Entity bean inheritance
- Inheritance is a key aspect of object-oriented software development and is a capability currently missing from the EJB specification.
The use of inheritance enables a developer to define fields, relationships, and business logic in a superclass entity bean that are inherited by all subclasses. See the section EJB inheritance of the Rational Application Developer (RAD) documentation for details on using inheritance with WAS and entity beans.
- Access Intent Policies
- Access intent policies provide Java EE application developers the mechanism by which they can indicate the intent of an application's interaction with the essential state for entity beans in order that the persistence mechanisms can make appropriate optimizations. For example, if it is known that an entity is not updated during the course of a transaction, then the persistence management is able to ease up on the concurrency control and still maintain data integrity by disallowing update operations on that bean for the duration of the transaction.
- Caching data across transactions
- Data caching across transactions is a configurable option set by the bean deployer that can greatly improve performance. Essentially, this is for data that changes infrequently. The option is known as LifetimeInCache. The data for an entity configured for lifetime in cache is stored in a cache until its specified lifetime expires. Requests on the entity during that configured lifetime use the cached data, and do not result in the execution of queries against the underlying data store. Lifetime can be expressed as time elapsed since the data was retrieved from the data store or until a specific time of day or week. The LifetimeInCache value can be one of the following:
See the LifetimeInCache help sections of the assembly tool for more details.
- Off
- The LifetimeInCache setting is ignored. Beans of this type are only cached in a transaction scoped cache. The cached data for this instance is not valid when the transaction is completed.
- ElapsedTime
- The value in the LifetimeInCache setting is added to the current time when the transaction (in which the bean instance is retrieved) is completed. The cached data for this instance is not valid after this time. The value of the LifetimeInCache setting can add up to minutes, hours, days, and so on.
- ClockTime
- The value of LifetimeInCache represents a particular time of day. The value is added to the immediately preceding or following midnight to calculate a future time value, which is then treated as for Elapsed Time. Using this setting enables you to specify that all instances of this bean type have their cached data invalidated at a specific time no matter when the data were retrieved.
The use of preceding or following midnight to calculate a future time value depends on the value of LifetimeInCache. If LifetimeInCache plus preceding midnight is earlier than the current time, then the following midnight is used.
When you use the ClockTime setting, the value of LifetimeInCache must not represent more than 24 hours. If it does, the cache manager subtracts increments of 24 hours from it until a value less than or equal to 24 hours is achieved. To invalidate data at 12 midnight, you set LifetimeInCache to zero (0).
- WeekTime
- This setting is similar to ClockTime, except the value of LifetimeInCache is added to the preceding or following Sunday midnight (actually, 11:59 PM on Saturday plus 1 minute). In this case, the LifetimeInCache value can represent more than 24 hours, but not more than 7 days.
Because the data used by an entity bean can be loaded by previous transactions, if we configure the bean as LifeTimeInCache, the isolation level and update lock (access intent policies) for the bean are lost for the current transaction. This can cause data integrity problems if the application has logic to calculate information from read-only data, and then save the result in another bean. This makes it important to perform read-read consistency checking to ensure the data get locked properly if loading the data from in-memory cache; otherwise, data is updated to the database without knowing the underlining data is changed, causing previous changes to be lost.
See Set read-read consistency checking with an assembly tool.
- Read-only entity beans
- Declaring entity beans as read-only potentially increases the performance enhancement offered by caching. Both features operate on the same principle: to minimize the overhead incurred by frequent reloading of entity beans from data in persistent storage. When you designate entity beans as read-only, we can specify the reload requirements and frequency, according to the needs of the application.
To use this function, you declare the bean type as read-only by selecting a particular set of bean caching options, through a selection list within the assembly tooling. See Develop read-only entity beans for details.
Subtopics
Container-managed persistence restrictions and exceptions
Application performance and entity bean behavior
Related concepts
Access intent policies
Related tasks
Set read-read consistency checking with an assembly tool
Develop read-only entity beans
Related
Data access: Links