31. Why do we have a remove method in both EJBHome and EJBObject?
With the EJBHome version of the remove, you are able to delete an entity bean
without first instantiating it (you can provide a PrimaryKey object as a
parameter to the remove method). The home version only works for entity beans.
On the other hand, the Remote interface version works on an entity bean that
you have already instantiated. In addition, the remote version also works on
session beans (stateless and Stateful) to inform the container of your loss of
interest in this bean.
32. How can I call one EJB from inside of another EJB?
EJBs can be clients of other EJBs. It just works. Use JNDI to locate the Home
Interface of the other bean, then acquire an instance reference, and so forth.
33. What is the difference between a Server, a Container, and a Connector?
An EJB server is an application, usually a product such as BEA Weblogic, that
provides (or should provide) for concurrent client connections and manages
system resources such as threads, processes, memory, database connections,
network connections, etc. An EJB container runs inside (or within) an EJB
server, and provides deployed EJB beans with transaction and security
management, etc. The EJB container insulates an EJB bean from the specifics of
an underlying EJB server by providing a simple, standard API between the EJB
bean and its container. A Connector provides the ability for any Enterprise
Information System (EIS) to plug into any EJB server which supports the
Connector architecture. See Sun’s J2EE Connectors for more in-depth
information on Connectors.
34. How is persistence implemented in enterprise beans?
Persistence in EJB is taken care of in two ways, depending on how you
implement your beans: container managed persistence (CMP) or bean managed
persistence (BMP) For CMP, the EJB container which your beans run under takes
care of the persistence of the fields you have declared to be persisted with
the database - this declaration is in the deployment descriptor. So, anytime
you modify a field in a CMP bean, as soon as the method you have executed is
finished, the new data is persisted to the database by the container. For BMP,
the EJB bean developer is responsible for defining the persistence routines in
the proper places in the bean, for instance, the ejbCreate(), ejbStore(),
ejbRemove() methods would be developed by the bean developer to make calls to
the database. The container is responsible, in BMP, to call the appropriate
method on the bean. So, if the bean is being looked up, when the create()
method is called on the Home interface, then the container is responsible for
calling the ejbCreate() method in the bean, which should have functionality
inside for going to the database and looking up the data.
35. What is an EJB Context?
EJBContext is an interface that is implemented by the container, and it is
also a part of the bean-container contract. Entity beans use a subclass of
EJBContext called EntityContext. Session beans use a subclass called
SessionContext. These EJBContext objects provide the bean class with
information about its container, the client using the bean and the bean
itself. They also provide other functions. See the API docs and the spec for
more details.
36. Is method overloading allowed in EJB?
Yes you can overload methods should synchronization primitives be used on bean
methods? - No. The EJB specification specifically states that the enterprise
bean is not allowed to use thread primitives. The container is responsible for
managing concurrent access to beans at runtime.
37. Are we allowed to change the transaction isolation property in middle
of a transaction?
No. You cannot change the transaction isolation level in the middle of
transaction.
38. For Entity Beans, What happens to an instance field not mapped to any
persistent storage, when the bean is passivated?
The specification infers that the container never serializes an instance of an
Entity bean (unlike Stateful session beans). Thus passivation simply involves
moving the bean from the ready to the pooled bin. So what happens to the
contents of an instance variable is controlled by the programmer. Remember
that when an entity bean is passivated the instance gets logically
disassociated from its remote object. Be careful here, as the functionality of
passivation/activation for Stateless Session, Stateful Session and Entity
beans is completely different. For entity beans the ejbPassivate method
notifies the entity bean that it is being disassociated with a particular
entity prior to reuse or for dereference.
39. What is a Message Driven Bean, what functions does a message driven
bean have and how do they work in collaboration with JMS?
Message driven beans are the latest addition to the family of component bean
types defined by the EJB specification. The original bean types include
session beans, which contain business logic and maintain a state associated
with client sessions, and entity beans, which map objects to persistent data.
Message driven beans will provide asynchrony to EJB based applications by
acting as JMS message consumers. A message bean is associated with a JMS topic
or queue and receives JMS messages sent by EJB clients or other beans. Unlike
entity beans and session beans, message beans do not have home or remote
interfaces. Instead, message driven beans are instantiated by the container as
required. Like stateless session beans, message beans maintain no
client-specific state, allowing the container to optimally manage a pool of
message-bean instances. Clients send JMS messages to message beans in exactly
the same manner as they would send messages to any other JMS destination. This
similarity is a fundamental design goal of the JMS capabilities of the new
specification. To receive JMS messages, message driven beans implement the
javax.jms.MessageListener interface, which defines a single onMessage()
method. When a message arrives, the container ensures that a message bean
corresponding to the message topic/queue exists (instantiating it if
necessary), and calls its onMessage method passing the client’s message as the
single argument. The message bean’s implementation of this method contains the
business logic required to process the message. Note that session beans and
entity beans are not allowed to function as message beans.
40. Does RMI-IIOP support code downloading for Java objects sent by value
across an IIOP connection in the same way as RMI does across a JRMP
connection?
Yes. The JDK 1.2 supports the dynamic class loading. The EJB container
implements the EJBHome and EJBObject classes. For every request from a unique
client,
41. Does the container create a separate instance of the generated EJBHome
and EJBObject classes?
The EJB container maintains an instance pool. The container uses these
instances for the EJB Home reference irrespective of the client request. While
referring the EJB Object classes the container creates a separate instance for
each client request. The instance pool maintenance 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. What is the advantage of putting an Entity Bean instance from the Ready
State to Pooled State?
The idea of the Pooled State is to allow a container to maintain a pool of
entity beans that has been created, but has not been yet synchronized or
assigned to an EJBObject. This mean that the instances do represent entity
beans, but they can be used only for serving Home methods (create or findBy),
since those methods do not relay on the specific values of the bean. All these
instances are, in fact, exactly the same, so, they do not have meaningful
state. Jon Thorarinsson has also added: It can be looked at it this way: If no
client is using an entity bean of a particular type there is no need for
cachig it (the data is persisted in the database). Therefore, in such cases,
the container will, after some time, move the entity bean from the Ready State
to the Pooled state to save memory. Then, to save additional memory, the
container may begin moving entity beans from the Pooled State to the Does Not
Exist State, because even though the bean’s cache has been cleared, the bean
still takes up some memory just being in the Pooled State.
43. What is the need of Remote and Home interface. Why can’t it be in one?
The main reason is because there is a clear division of roles and
responsibilities between the two interfaces. The home interface is your way to
communicate with the container, that is that is responsible of creating,
locating even removing one or more beans. The remote interface is your link to
the bean that will allow you to remotely access to all its methods and
members. As you can see there are two distinct elements (the container and the
beans) and you need two different interfaces for accessing to both of them.
44. Can I develop an Entity Bean without implementing the create() method
in the home interface?
As per the specifications, there can be 'ZERO' or 'MORE' create() methods
defined in an Entity Bean. In cases where create() method is not provided, the
only way to access the bean is by knowing its primary key, and by acquiring a
handle to it by using its corresponding finder method. In those cases, you can
create an instance of a bean based on the data present in the table. All one
needs to know is the primary key of that table. I.e. a set a columns that
uniquely identify a single row in that table. Once this is known, one can use
the 'getPrimaryKey()' to get a remote reference to that bean, which can
further be used to invoke business methods.
What is the difference between Context, InitialContext and Session Context?
How they are used? javax.naming.Context is an interface that provides methods
for binding a name to an object. It's much like the RMI Naming.bind() method.
javax.naming.InitialContext is a Context and provides implementation for
methods available in the Context interface.
Where as SessionContext is an EJBContext objects that is provided by the EJB
container to a SessionBean in order for the SessionBean to access the
information and/or services or the container.
There is EntityContext too which is also and EJBContext object that'll be
provided to an EntityBean for the purpose of the EntityBean accessing the
container details. In general, the EJBContext (SessionContext and
EntityContext), AppletContext and ServletContext help the corresponding Java
objects in knowing about its 'context' [environment in which they run], and to
access particular information and/or service. Whereas, the
javax.naming.Context is for the purpose of 'NAMING' [by the way of referring
to] an object.
45. Why an onMessage call in Message-driven bean is always a separate
transaction?
EJB 2.0 specification: "An onMessage call is always a separate transaction,
because there is never a transaction in progress when the method is called."
When a message arrives, it is passed to the Message Driven Bean through the
onMessage() method, that is where the business logic goes. Since there is no
guarantee when the method is called and when the message will be processed, is
the container that is responsible of managing the environment, including
transactions.