|
Placement
Papers
>>
Java
>>
Masterlist Of
Java
Interview Questions -115
-
How EJB
Invocation happens? - Retrieve Home Object reference
from Naming Service via JNDI. Return Home Object reference
to the client. Create me a new EJB Object through Home
Object interface. Create EJB Object from the Ejb Object.
Return EJB Object reference to the client. Invoke business
method using EJB Object reference. Delegate request to Bean
(Enterprise Bean).
-
Is it
possible to share an HttpSession between a JSP and EJB?
What happens when I change a value in the HttpSession from
inside an EJB? - You can pass the HttpSession as
parameter to an EJB method, only if all objects in session
are serializable.This has to be consider as
passed-by-value, that means that it’s read-only in the EJB.
If anything is altered from inside the EJB, it won’t be
reflected back to the HttpSession of the Servlet
Container.The pass-by-reference can be used between EJBs
Remote Interfaces, as they are remote references. While it
is possible to pass an HttpSession as a parameter to
an EJB object, it is considered to be bad practice in terms
of object-oriented design. This is because you are creating
an unnecessary coupling between back-end objects (EJBs) and
front-end objects (HttpSession). Create a higher-level of
abstraction for your EJBs API. Rather than passing the
whole, fat, HttpSession (which carries with it a bunch of
http semantics), create a class that acts as a value object
(or structure) that holds all the data you need to pass
back and forth between front-end/back-end. Consider the
case where your EJB needs to support a non HTTP-based
client. This higher level of abstraction will be flexible
enough to support it.
-
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? - 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 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.
-
Can the
primary key in the entity bean be a Java primitive type
such as int? - 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).
-
Can you
control when passivation occurs? - 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).
-
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? - 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.
-
What is EJB
QL? - 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.
-
Brief
description about local interfaces? - EEJB 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 the
special design care that must be taken when you work with
local interfaces? - It is important to understand that
the calling semantics of local interfaces are different
from those of remote interfaces. For example, remote
interfaces pass parameters using call-by-value semantics,
while local interfaces use call-by-reference. This means
that in order to use local interfaces safely, application
developers need to carefully consider potential deployment
scenarios up front, then decide which interfaces can be
local and which remote, and finally, develop the
application code with these choices in mind. While EJB 2.0
local interfaces are extremely useful in some situations,
the long-term costs of these choices, especially when
changing requirements and component reuse are taken into
account, need to be factored into the design decision.
-
What happens
if remove( ) is never invoked on a session bean? - In
case of a stateless session bean it may not matter if we
call or not as in both cases nothing is done. The number of
beans in cache is managed by the container. In case of
stateful session bean, the bean may be kept in cache till
either the session times out, in which case the bean is
removed or when there is a requirement for memory in which
case the data is cached and the bean is sent to free pool.
-
What is the
difference between Message Driven Beans and Stateless
Session beans? - In several ways, the dynamic creation
and allocation of message-driven bean instances mimics the
behavior of stateless session EJB instances, which exist
only for the duration of a particular method call. However,
message-driven beans are different from stateless session
EJBs (and other types of EJBs) in several significant ways:
Message-driven beans process multiple JMS messages
asynchronously, rather than processing a serialized
sequence of method calls. Message-driven beans have no home
or remote interface, and therefore cannot be directly
accessed by internal or external clients. Clients interact
with message-driven beans only indirectly, by sending a
message to a JMS Queue or Topic. Only the container
directly interacts with a message-driven bean by creating
bean instances and passing JMS messages to those instances
as necessary. The Container maintains the entire lifecycle
of a message-driven bean; instances cannot be created or
removed as a result of client requests or other API calls.
-
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.
-
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.
|
|
