WebSphere Application Server delivers container-managed persistence
(CMP) services beyond the standards set by the Enterprise JavaBean (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. WebSphere Application
Server 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 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 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.
See the LifetimeInCache help sections of the assembly
tool for more details. Note: Because the data used by an entity bean can
be loaded by previous transactions, if you 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 your 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. For more information, see Configuring read-read consistency checking with the assembly tools.
- 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,
you can specify the reload requirements and frequency, according to the needs
of your 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 application assembly tooling (either Rational Application
Developer or the Application Server Toolkit). See Developing read-only entity beans for details.