Is it legal to have static initializer blocks in EJB?
Although technically it is legal, static initializer
blocks are used to execute some piece of code before executing any constructor
or method while instantiating a class. Static initializer
blocks are also typically used to initialize static fields - which may be
illegal in EJB if they are read/write - In EJB this can be achieved by
including the code in either the ejbCreate(), setSessionContext() or setEntityContext()
methods
What are Local Interfaces?
Describe.
EJB was originally designed around remote invocation using the Java Remote
Method Invocation (RMI) mechanism, and later extended to support to standard
CORBA transport for these calls using RMI/IIOP. This design allowed for maximum
flexibility in developing applications without consideration for the deployment
scenario, and was a strong feature in support of a goal of component reuse in
J2EE. Many developers are using EJBs locally, that is, some or all of their EJB
calls are between beans in a single container. With this feedback in mind, the
EJB 2.0 expert group has created a local interface mechanism. The local
interface may be defined for a bean during development, to allow streamlined
calls to the bean if a caller is in the same container. This does not involve
the overhead involved with RMI like marshalling etc. This facility will thus
improve the performance of applications in which co-location is planned. Local
interfaces also provide the foundation for container-managed relationships
among entity beans with container-managed persistence.
What are transaction isolation levels in EJB?
1. Transaction_read_uncommitted- Allows a method to
read uncommitted data from a DB(fast but not wise).
2. Transaction_read_committed- Guarantees that the
data you are getting has been committed.
3. Transaction_repeatable_read - Guarantees that all
reads of the database will be the same during the transaction (good for read
and update operations).
4. Transaction_serializable- All the transactions for
resource are performed serial.
Can Entity Beans have no create() methods?
Yes. In some cases the data is inserted NOT using Java application, so you may
only need to retrieve the information, perform its processing, but not create
your own information of this kind.
What is software architecture of EJB?
Session and Entity EJBs consist of 4 and 5 parts respetively:
1. A remote interface (a client interacts with it),
2. A home interface (used for creating objects and for declaring business
methods),
3. A bean object (an object, which actually performs
business logic and EJB-specific operations).
4. A deployment descriptor (an XML file containing all information required for
maintaining the EJB) or a set of deployment descriptors (if you are using some
container-specific features).
5.A Primary Key class - is only Entity bean specific.
What are the callback methods in Entity beans?
The bean class defines create methods that match methods in the home interface
and business methods that match methods in the remote interface. The bean class
also implements a set of callback methods that allow the container to notify
the bean of events in its life cycle. The callback methods are defined in the javax.ejb.EntityBean interface that is implemented by all
entity beans.The EntityBean
interface has the following definition. Notice that the bean class implements
these methods.
public interface javax.ejb.EntityBean {
public void setEntityContext();
public void unsetEntityContext();
public void ejbLoad();
public void ejbStore();
public void ejbActivate();
public void ejbPassivate();
public void ejbRemove();
}
The setEntityContext() method provides the bean with
an interface to the container called the EntityContext.
The EntityContext interface contains methods for obtaining
information about the context under which the bean is operating at any
particular moment. The EntityContext interface is
used to access security information about the caller; to determine the status
of the current transaction or to force a transaction rollback; or to get a
reference to the bean itself, its home, or its primary key. The EntityContext is set only once in the life of an entity
bean instance, so its reference should be put into one of the bean instance’s
fields if it will be needed later.
The unsetEntityContext() method is used at the end of the bean’s life cycle before
the instance is evicted from memory to dereference the EntityContext
and perform any last-minute clean-up.
The ejbLoad() and ejbStore() methods in CMP
entities are invoked when the entity bean’s state is being synchronized with
the database. The ejbLoad() is invoked just after the container has refreshed the
bean container-managed fields with its state from the database. The ejbStore()
method is invoked just before the container is about to write the bean
container-managed fields to the database. These methods are used to modify data
as it’s being synchronized. This is common when the
data stored in the database is different than the data used in the bean fields.
The ejbPassivate() and ejbActivate() methods are
invoked on the bean by the container just before the bean is passivated and just after the bean is activated,
respectively. Passivation in entity beans means that
the bean instance is disassociated with its remote reference so that the
container can evict it from memory or reuse it. It’s a resource conservation
measure the container employs to reduce the number of instances in memory. A
bean might be passivated if it hasn’t been used for a
while or as a normal operation performed by the container to maximize reuse of
resources. Some containers will evict beans from memory, while others will
reuse instances for other more active remote references. The ejbPassivate()
and ejbActivate() methods provide the bean with a notification
as to when it’s about to be passivated (disassociated
with the remote reference) or activated (associated with a remote reference).
No comments:
Post a Comment