Read-Only Beans

Another feature that the GlassFish Server provides is the read-only
bean, an EJB 2.1 entity bean that is never modified by
an EJB client. Read-only beans avoid database updates completely.

Note –

Read-only beans are specific to the GlassFish Server and
are not part of the Enterprise JavaBeans Specification, v2.1. Use
of this feature for an EJB 2.1 bean results in a non-portable application.

To make an EJB 3.0 entity read-only, use @Column annotations
to mark its columns insertable=false and updatable=false.

A read-only bean can be used to cache
a database entry that is frequently accessed but rarely updated (externally
by other beans). When the data that is cached by a read-only bean
is updated by another bean, the read-only bean can be notified to
refresh its cached data.

The GlassFish Server provides a number of ways by which a read-only
bean’s state can be refreshed. By setting the refresh-period-in-seconds element in the sun-ejb-jar.xml file
and the trans-attribute element (or @TransactionAttribute annotation) in the ejb-jar.xml file,
it is easy to configure a read-only bean that is one of the following:

Always refreshed

Periodically refreshed

Never refreshed

Programmatically refreshed

Read-only beans are best suited for situations where the underlying
data never changes, or changes infrequently. For further information
and usage guidelines, see Using Read-Only Beans.

Pooling and Caching

The EJB container of the GlassFish Server pools anonymous instances
(message-driven beans, stateless session beans, and entity beans)
to reduce the overhead of creating and destroying objects. The EJB
container maintains the free pool for each bean that is deployed.
Bean instances in the free pool have no identity (that is, no primary
key associated) and are used to serve method calls. The free beans
are also used to serve all methods for stateless session beans.

Bean instances in the free pool transition from a Pooled state
to a Cached state after ejbCreate and the
business methods run. The size and behavior of each pool is controlled
using pool-related properties in the EJB container or the sun-ejb-jar.xml file.

In addition, the GlassFish Server supports a number of tunable
parameters that can control the number of “stateful” instances
(stateful session beans and entity beans) cached as well as the duration
they are cached. Multiple bean instances that refer to the same database
row in a table can be cached. The EJB container maintains a cache
for each bean that is deployed.

To achieve scalability, the container selectively evicts some
bean instances from the cache, usually when cache overflows. These
evicted bean instances return to the free bean pool. The size and
behavior of each cache can be controlled using the cache-related properties
in the EJB container or the sun-ejb-jar.xml file.

Pooling Parameters

One of the most important parameters of GlassFish Server pooling
is steady-pool-size. When steady-pool-size is
set to greater than 0, the container not only pre-populates the bean
pool with the specified number of beans, but also attempts to ensure
that this number of beans is always available in the free pool. This
ensures that there are enough beans in the ready to serve state to
process user requests.

This parameter does not necessarily guarantee that no more than steady-pool-size instances exist at a given time. It only
governs the number of instances that are pooled over a long period
of time. For example, suppose an idle stateless session container
has a fully-populated pool with a steady-pool-size of 10. If 20 concurrent requests arrive for the EJB component,
the container creates 10 additional instances to satisfy the burst
of requests. The advantage of this is that it prevents the container
from blocking any of the incoming requests. However, if the activity
dies down to 10 or fewer concurrent requests, the additional 10 instances
are discarded.

Another parameter, pool-idle-timeout-in-seconds,
allows the administrator to specify the amount of time a bean instance
can be idle in the pool. When pool-idle-timeout-in-seconds is
set to greater than 0, the container removes or destroys any bean
instance that is idle for this specified duration.

Caching Parameters

GlassFish Server provides a way that completely avoids caching
of entity beans, using commit option C. Commit option C is particularly
useful if beans are accessed in large number but very rarely reused.
For additional information, refer to Commit Options.

The GlassFish Server caches can be either bounded or unbounded. Bounded caches have limits on the number of beans that
they can hold beyond which beans are passivated. For stateful session
beans, there are three ways (LRU, NRU and FIFO) of picking victim
beans when cache overflow occurs. Caches can also passivate beans
that are idle (not accessed for a specified duration).

Bean-Level Container-Managed Transaction
Timeouts

The default transaction timeout for the domain is specified
using the Transaction Timeout setting of the Transaction Service.
A transaction started by the container must commit (or rollback) within
this time, regardless of whether the transaction is suspended (and
resumed), or the transaction is marked for rollback.

To override this timeout for an individual bean, use the optional cmt-timeout-in-seconds element in sun-ejb-jar.xml.
The default value, 0, specifies that the default
Transaction Service timeout is used. The value of cmt-timeout-in-seconds is used for all methods in the bean that start a new container-managed
transaction. This value is not used if the bean
joins a client transaction.

Priority Based Scheduling of Remote Bean
Invocations

You can create multiple thread pools, each having its own work
queues. An optional element in the sun-ejb-jar.xml file, use-thread-pool-id, specifies the thread pool that processes
the requests for the bean. The bean must have a remote interface,
or use-thread-pool-id is ignored. You can create
different thread pools and specify the appropriate thread pool ID
for a bean that requires a quick response time. If there is no such
thread pool configured or if the element is absent, the default thread
pool is used.

Immediate Flushing

Normally, all entity bean updates within a transaction are batched
and executed at the end of the transaction. The only exception is
the database flush that precedes execution of a finder or select query.

Since a transaction often spans many method calls, you might
want to find out if the updates made by a method succeeded or failed
immediately after method execution. To force a flush at the end of
a method’s execution, use the flush-at-end-of-method element
in the sun-ejb-jar.xml file. Only non-finder
methods in an entity bean can be flush-enabled. (For an EJB 2.1 bean,
these methods must be in the Local, Local Home, Remote, or Remote
Home interface.) See flush-at-end-of-method in Oracle GlassFish Server 3.0.1 Application Deployment Guide.

Upon completion of the method, the EJB container updates the
database. Any exception thrown by the underlying data store is wrapped
as follows:

If the method that triggered the flush is a create method, the exception is wrapped with CreateException.

If the method that triggered the flush is a remove method, the exception is wrapped with RemoveException.

For all other methods, the exception is wrapped with EJBException.

All normal end-of-transaction database synchronization steps
occur regardless of whether the database has been flushed during the
transaction.