What happens to instance variables when an entity bean is passivated?

Passivation is no synonym for Serialization. Passivation simply means that the EJB instance will be freed from the data its variables are storing which in other words is moving to pooled state. But before doing so, it may call ejbStore method so as to save the state of the EJB instance and then calling ejbPassivate method so as to give a chance to developer to free up the resources.

Thus when passivating, the instance variables are stored in database.

What is the difference between optimistic locking and pessimistic locking?

Optimistic Locking : Here it is assumed that there is no need to lock the database row as it is assumed that the database state is not going to be change in the due course of time. If it is found that the state has changed then the transaction is rolled back. This is used in large scale systems as locking and unlocking rows every time increases execution time.


Pessimistic locking: In this mechanism, the database rows are locked for the period of transaction thus no other transaction can update the data. This is usually used in case of small scale systems.

What are ACID properties?

ACID stands for the properties which should be met with when a transaction completes. The individual properties are:

A- Atomicity (The whole transaction should be treated as a single statement i.e. either all the statements of transaction are executed or none)
C- Consistency (The updation of database is done so that all database are consistent and there is no inconsistent data in different tables)
I- Isolation (Transactions must run itself without the interference of other transactions or processes)
D- Durability (Once a transaction completes, the changes are durable and kept in some form of physical storage)

What is business delegate pattern and how is it different from service locator pattern?

When coding a J2EE application, the client needs to

1) look up the home component
2) get the remote component by calling create/finder method

While doing so, the look up code is always same except the look up string so to create a class with the look up code can help reduce the repetition of same code and hence the name service locator. Service locator is the best candidate for singleton pattern because a single instance can service every time.

The second point mentioned above can't be coded in client code every time we need to use the model as it will reduce maintainability. Moreover, we need to shield the client from handling model exceptions like CreateException, RemoteException etc.

Thus to handle the complexities of using model, Business delegate class is used.

According to SUN, a typical business delegate costructor may look like:

public AdminRequestBD() throws AdminBDException {
try {
OPCAdminFacadeHome home = (OPCAdminFacadeHome) ServiceLocator.getInstance().getRemoteHome(OPC_ADMIN_NAME, OPCAdminFacadeHome.class);
opcAdminEJB = home.create();
} catch (ServiceLocatorException sle) {
throw new AdminBDException(sle.getMessage());
} catch (CreateException ce) {
throw new AdminBDException(ce.getMessage());
} catch (RemoteException re) {
throw new AdminBDException(re.getMessage());
}
}

What is the difference between fine grained and coarse grained entity beans?

A fine grained entity bean is the one which is mapped to one table only while a coarse grained entity bean is the one which is mapped to more than one tables or single table representing multiple objects.

It is quit obvious that by using coarse grained beans, the number of network calls to database can be reduced because bulk data gets transferred and hence sometimes coarse grained entity beans are used to improve the performance.

What is the need of having remove method in home and remote interfaces?

The home version can only be used with entity beans by providing the primary key and can't be used with session beans.

The remote version can be used to remove any bean which has been instantiated be it session or entity bean.

What is the default transaction attribute for EJB?

The EJB specification doesn't mention a default attribute but leaves it to the application server to maintain a default transaction attribute.

For weblogic, the default transaction attribute is "Supports"