JSP Servlet J2EE Questions 9

41: The EJB container implements the EJBHome and EJBObject classes. For every request from a unique client, does the container create a separate instance of the generated EJBHome and EJBObject classes?
A: The EJB container maintains an instance pool. The container uses these
instances for the EJB Home reference irrespective of the client request. while
refering the EJB Object classes the container creates a separate instance for each
client request. The instance pool maintainence is up to the implementation of the
container. If the container provides one, it is available otherwise it is not
mandatory for the provider to implement it. Having said that, yes most of the
container providers implement the pooling functionality to increase the performance
of the application server. The way it is implemented is again up to the
implementer.

42: Can the primary key in the entity bean be a Java primitive type such as int?
A: The primary key can't be a primitive type--use the primitive wrapper
classes, instead. For example, you can use java.lang.Integer as the primary key
class, but not int (it has to be a class, not a primitive)

43: Can you control when passivation occurs?
A: The developer, according to the specification, cannot directly control when
passivation occurs. Although for Stateful Session Beans, the container cannot
passivate an instance that is inside a transaction. So using transactions can be a
a strategy to control passivation.
The ejbPassivate() method is called during passivation, so the developer has
control over what to do during this exercise and can implement the require
optimized logic.
Some EJB containers, such as BEA WebLogic, provide the ability to tune the
container to minimize passivation calls.
Taken from the WebLogic 6.0 DTD -"The passivation-strategy can be either "default"
or "transaction". With the default setting the container will attempt to keep a
working set of beans in the cache. With the "transaction" setting, the container
will passivate the bean after every transaction (or method call for a
non-transactional invocation).

44: What is the advantage of using Entity bean for database operations, over
directly using JDBC API to do database operations? When would I use one over the other?
A: Entity Beans actually represents the data in a database. It is not that
Entity Beans replaces JDBC API. There are two types of Entity Beans Container
Managed and Bean Mananged. In Container Managed Entity Bean - Whenever the instance
of the bean is created the container automatically retrieves the data from the
DB/Persistance storage and assigns to the object variables in bean for user to
manipulate or use them. For this the developer needs to map the fields in the
database to the variables in deployment descriptor files (which varies for each
vendor).
In the Bean Managed Entity Bean - The developer has to specifically make
connection, retrive values, assign them to the objects in the ejbLoad() which will
be called by the container when it instatiates a bean object. Similarly in the
ejbStore() the container saves the object values back the the persistance storage.
ejbLoad and ejbStore are callback methods and can be only invoked by the container.
Apart from this, when you use Entity beans you dont need to worry about database
transaction handling, database connection pooling etc. which are taken care by the
ejb container. But in case of JDBC you have to explicitly do the above features.
what suresh told is exactly perfect. ofcourse, this comes under the database
transations, but i want to add this. the great thing about the entity beans of
container managed, whenever the connection is failed during the transaction
processing, the database consistancy is mantained automatically. the container
writes the data stored at persistant storage of the entity beans to the database
again to provide the database consistancy. where as in jdbc api, we, developers has
to do manually.

45: What is EJB QL?
A: EJB QL is a Query Language provided for navigation across a network of
enterprise beans and dependent objects defined by means of container managed
persistence. EJB QL is introduced in the EJB 2.0 specification. The EJB QL query
language defines finder methods for entity beans with container managed
persistenceand is portable across containers and persistence managers. EJB QL is
used for queries of two types of finder methods: Finder methods that are defined in
the home interface of an entity bean and which return entity objects. Select
methods, which are not exposed to the client, but which are used by the Bean
Provider to select persistent values that are maintained by the Persistence Manager
or to select entity objects that are related to the entity bean on which the query
is defined.