WebSphere® Application
Server delivers container-managed persistence (CMP) services beyond
the standards set by the Enterprise JavaBeans (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
documentation for details on using inheritance with WebSphere Application Server and entity
beans.
- Access Intent Policies
- Access intent policies provide Java Platform,
Enterprise Edition (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:
- 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 the topic Configuring 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, 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 assembly tooling. See Configuring read-read consistency
checking with an assembly tool for details.