Container-managed persistence features
The container-managed persistence (CMP) features include those defined by the EJB 2.0 Specification, as well as capabilities that are beyond the specification.
EJB 2.0 specified capabilities
Container-Managed Relationships (CMR) is one of the most significant new features added by the EJB 2.0 Specification. Like Inheritance, relationships are a key component of object-oriented software development and non-trivial object models can form complex networks with these relationships. The EJB 2.0 Specification adds relationships to the EJB programming model and requires that the container be responsible for their maintenance.
The container automatically manages the state of CMP entity beans. This management includes synchronizing the state of the bean with the underlying database when necessary and also managing any relationships (CMRs) with other entity beans. The bean developer is relieved of writing any database specific code and, instead, can focus on business logic.
Local interfaces are another feature introduced in the EJB 2.0 Specification. Local component interfaces allow collocated beans to interact without the overhead associated with remote access.
Value-add features
Several capabilities are provided to enhance the function of CMP entity beans that go beyond those capabilities defined by the specification. These include:
- Entity bean inheritance
- Inheritance is a key aspect of object-oriented software development and
is a capability currently missing from the EJB 2.0 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 WebSphere Studio Application Developer (WSAD) documentation for details on using inheritance with WebSphere Application Server and entity beans.
- Access Intent Policies
- Access intent policies provide J2EE 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:
- 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 ClockTime, 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.
Access intent policies
Data access : Resources for learning