EJB Notes
EJB Notes
RMI
EJB2.0
EJB2.1
EJB3.0
EJB3.1
Networking
yes
yes
yes
yes
yes
Streams
yes
yes
yes
yes
yes
Threads
yes
yes
yes
yes
Yes
Middle-level services
6
Remoting services
yes
yes
yes
yes
Yes
Transaction Services
(JTS)
No
yes
yes
yes
yes
Security Management
(JAAS)
No
Yes
Yes
Yes
Yes
Persistence Management
No
Yes
Yes
Yes
Yes
10
Messaging(JMS,MDB)
No
Yes
Yes
Yes
Yes
11
Timer Service
No
No
Yes
Yes
Yes
12
Resource Management
No
Yes
Yes
Yes
Yes
13
No
Yes
Yes
Yes
Yes
14
No
No
No
Yes
Yes
15
Dependency Injection
No
No
No
Yes
Yes
16
Interceptors
No
No
No
Yes
Yes
When you develop the EJB2 SLSB, you need to check the following.
A) Home Interface
1) Home interface can extend EJBHome or EJBLocalHome.
2) Home interface should contain create() method and should not be
overloaded.
3) Home interface create() method must return business interface
object.
4) If Home interface is extending EJBHome then create() method must
throw CreateException,RemoteException.
5) If Home interface is extending EJBLocalHome then create() method
must throw CreateException.
B) Business interface
1) Business interface can extend EJBobject or EJBLocalObject.
2) Business interface should contain any business logic methods
which you want to expose to remote client or local client.
3) If Business interface is extending EJBobject then business logic
methods musth throw RemoteException.
Containser Tasks
No Actions
2)Client
invokes the
Business
operation
3)No Action
B) Bean Class
1) Bean class has to marked with @Stateless annotations.
2) Bean class has to implement Business interface directly and has to
override all the business logic method of Business interface.
3) If you want to initialize the Bean interface with resources like
SessionContext , UserTransaction etc then mark them with @Resource
annotation.
4) If you want to initialize the Bean instance with any other resources
then write your own method with initialization code and mark that with
@PostConstruct annotation.
5) If you want to clean the resources then write your own method with
cleanup code and mark that with @PreDestroy annotation.
C) EJB3 SLSBs resource management technique is instance pooling.
Client Tasks
Containser Tasks
No Actions
2)Client
invokes the
Business
operation
3)No Action
Interview Questions
1). What are the Differences between EJB 3.0 and EJB 2.1?
Differences are:
1) EJB 3.0 allows developers to program EJB components as ordinary Java objects
with ordinary Java business interfaces rather than as heavy weight components like
EJB 2 (home, remote).
2) In EJB 3.0 you can use annotation or deployment descriptors but in EJB 2 you
have to use deployment descriptors.
3) EJB 3 introduced persistence API for database access. In EJB 2 you can use
Entity bean.
4) EJB 3.0 is much faster the EJB2
2). What are the key features of the EJB technology?
1. EJB components are server-side components written entirely in the Java
programming language
2. EJB components contain business logic only - no system-level
programming & services, such as transactions, security, life-cycle, threading,
persistence, etc. are automatically managed for the EJB component by the
EJB server.
3. EJB architecture is inherently transactional, distributed, portable multitier, scalable and secure.
4. EJB components are fully portable across any EJB server and any OS.
5. EJB architecture is wire-protocol neutralany protocol can be utilized like
IIOP,JRMP, HTTP, DCOM,etc.
3). What is the difference between EJB and RMI
Both of them are java solution for distributed computing.
RMI offers remote access to an object running in another JVM and no other
services.
But EJB offers far more services than RMI apart from remote method calling. EJB
leverages this remote-object feature of RMI and ORB (RMI-IIOP) which can be
called by any COBRA client, but also provides other services such as persistence,
transaction management, security, resource management, object pooling and
messaging.
4).What are the ways for a client application to get an EJB object?
1. The client has the JNDI name of the EJB object; this name is used to get the
EJB object.
2) The client has the JNDI name of the Home object, this is a more usual
case; this name is used to get the Home object, then a finder method is
invoked on this Home to obtain one or several entity bean objects. The client
may also invoke a "create" method on the Home object to create a new EJB
object (session or entity).
3) The client has got a handle on an EJB object. A handle is an object that
identifies an EJB object; it may be serialized, stored, and used later by a
client to obtain a reference to the EJB Object, using the getEJBObject
method().
4) The client has got a reference to an EJB object, and some methods
defined on the remote interface of this Enterprise Bean return EJB objects.
5). What are the different kinds of enterprise beans?
Stateless session bean- An instance of these non-persistent EJBs provides a service
without storing an interaction or conversation state between methods. Any instance
can be used for any client.
Stateful session bean- An instance of these non-persistent EJBs maintains state
across methods and transactions. Each instance is associated with a particular
client.
Entity bean- An instance of these persistent EJBs represents an object view of the
data, usually rows in a database. They have a primary key as a unique identifier.
Entity bean persistence can be either container-managed or bean-managed.
Message-driven bean- An instance of these EJBs is integrated with the Java
Message Service (JMS) to provide the ability for message-driven beans to act as a
standard JMS message consumer and perform asynchronous processing between
the server and the JMS message producer.
* properties
* persistence
Enterprise JavaBeans (EJBs) are Java-based software components that are built to
comply with Java's EJB specification and run inside of an EJB container supplied
by a J2EE provider. An EJB container provides distributed application
functionality such as transaction support,
17). What are the Interfaces need to create to implement Session
Bean with Exmaple?
Session bean class (CartBean)
Home interface (CartHome)
Remote interface (Cart)
Session bean class (CartBean) :
public class CartBean implements SessionBean {
String customerName;
String customerId;
Vector contents;
public void ejbCreate(String person)
throws CreateException {
if (person == null) {
throw new CreateException("Null person not allowed.");
}
else {
customerName = person;
}
customerId = "0";
contents = new Vector();
}
return contents;
}
public CartBean() {}
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setSessionContext(SessionContext sc) {}
}
Home Interface:
public interface CartHome extends EJBHome {
Cart create(String person) throws
RemoteException, CreateException;
Cart create(String person, String id) throws
RemoteException, CreateException;
}
The signatures of the ejbCreate and create methods are similar, but differ in
important ways. The rules for defining the signatures of the create methods of a
home interface follow.
The number and types of arguments in a create method must match those of its
corresponding ejbCreate method.
The arguments and return type of the create method must be valid RMI types.
A create method returns the remote interface type of the enterprise bean. (But an
ejbCreate method returns void.)
The throws clause of the create method must include the
java.rmi.RemoteException and the javax.ejb.CreateException
Remote Interface :
public interface Cart extends EJBObject {
Stateless session bean are used when there is no conversational state and when
session bean has to be used only for database access
21). What is the difference between Stateful session bean and Stateless session
bean?
1. A stateful session beans can keep data between client accesses. wheras a
stateless session bean cannot.
2) A stateful seesion bean contain the state of client after seesion is expired.
whereas a stateless bwan cnanot.
3) A stateful session beans use the bean of pools for client application n after
use them it return the bean in the pool. whereas a stateless session bean
cannot.
22). What are the callbacks method in Session Bean ?
public void ejbCreate() {}
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setSessionContext(SessionContext sc) {}
23). How is Stateful Session bean maintain their states with client?
When a client refers to a Stateful Session object reference, all calls are directed to
the same object on the EJB container. The container does not require client identity
information or any cookie object to use the correct object.
This means that for a client to ensure that calls are directed to the same object on
the container, all it has to do is to use same reference for every call.
For example the following holds for all stateful session beans:
StatefulHome sfh = ...//get home interface for stateful bean
Stateful bean1 = sfh.create();
Stateful bean2 = sfh.create();
if (bean1.isIdentical(bean1)){} //this is true!
if (bean1.isIdentical(bean2)){} //this is false!
//Note that the second test would evaluate to true for stateless beans
Thus, if you're calling a Stateful Session Bean from a servlet, your servlet need to
keep the reference to the remote object in the HttpSession object between client
calls for you to be able to direct calls to the same object on the container.
Likewise, if you're calling from an application, you only obtain the reference to the
bean once and reuse the object throughout the application session.
24). What is the free pool?
The free pool is a data structure the EJB container uses to cache anonymous
instances of a given bean type. The free pool improves performance by reusing
objects and skipping container callbacks when it can.
25). Without home and remote interfaces cant we implement ejb?
Was just reading about EJB 3.0. I suppose with EJB 3.0, Home interface is
absolutely gone and implementing Business Interface is not mandatory. All
enterprise beans in EJB 3.0 are just POJO (Plain Old Java Object) with appropriate
annotations.
26). When are stateless EJBs passivated?
Stateless ejbs are never passivated. Since stateless ejbs do not have state, there is
no need to passivate them. They are put back into the free pool after each method
call so they will be available to service other requests.
27). 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.
28). What is handle and why it is used in EJB?
The handle mechanism allows a client application to maintain a reference to an
EJB object. A handle object may be obtained by calling the getHandle() method on
the reference to an EJB object. The main interest is that the handle class
implements java.io.serializable interface, which means that a handle may be
serialized. This allows the client to store the handle, or to pass it to another process.
The handle may then be deserialized and used to obtain the reference to the EJB
object, by calling the getEJBObject() method.
Handles on session bean objects are valid until the session bean object exists, i.e.
their life time is limited to that of the client. Handles on entity bean objects are
valid during the complete life time of the entity bean object; this means that such
handles may be used by different clients and stored for a long time; the EJB server
holding the entity bean objects may be stopped and restarted, the handle will still
be valid.
If we consider the entity bean object of the example above (a2), the way to obtain a
handle on this object is the following (the handle class is defined in the javax.ejb
package):
Handle h = a2.getHandle();The handle object may then be serialized and stored in
a file:
ObjectOutputStream out = new ObjectOutputStream(new
FileOutputStream("handlefile"));
out.writeObject(h);
out.close();
Then, a client can read the handle, and retrieve the referenced object:
ObjectInputStream in = new ObjectInputStream(new
FileInputStream("handlefile"));
Handle h = (Handle) in.readObject();
Account a = (Account)PortableRemoteObject.narrow(h.getEJBObject(),
Account.class);
The EJB Specification allows the client to obtain a handle for the home interface.
This allows the client to store a reference to an entity bean's home interface in
stable storage. The client code must use the
javax.rmi.PortableRemoteObject.narrow(...) method to convert the result of the
getEJBHome() method invoked on a handle to the home interface type
29). Implement Local and Remote Interfaces in EJB?
Remote BeansThe EJB 1.1 specification defines all EJBs as remote objects. This
means that every time you make a call to an EJB, you are making a remote call.
This means that there is considerable overhead to each EJB call, and hence
performance implications. To combat this, server vendors invented a way of
circumventing the remote calls to some degree. Oracle's solution with OC4J was
the pass-by-reference setting, which determined whether EJB objects were
communicated by reference to the object, or whether the whole object had to be
.
Note that now the local interfaces no longer throw the RemoteException, showing
that they are not remotely called methods. Also, the XML contains different
elements. There is now a local-home and a local tag. Also we are declaring that this
is an EJB 2.x bean, using the cmp-version tag.
Calling Local BeansCalling a local bean from Java code is very simple, and very
similar to using a remote bean. The code to call a remote bean is shown below.
try
{
Context ctx = new InitialContext();
Object o = ctx.lookup("Emp");
EmpHome empHome = PortableRemoteObject.narrow(o, EmpHome.class)
return empHome.findByDeptno(getDeptno());
}
catch (RemoteException r)
{
System.err.println("Error loading Employees(Remote): " + r.getMessage()); return
null;
}
catch (NamingException n)
{
System.err.println("Error loading Employees(Naming): " + n.getMessage());
return null;
}
catch (FinderException f)
{
System.err.println("Error loading Employees(Finder): " + f.getMessage());
return null;
}
The code for a local bean is similar, but we no longer have to worry about the
PortableRemoteObject, as the bean is no longer remote.
try
{
Context ctx = new InitialContext();
Object o = ctx.lookup("java:comp/env/LocalEmp");
EmpHome empHome = (EmpHome)o;
return empHome.findByDeptno(getDeptno());
}
catch (NamingException n)
{
System.err.println("Error loading Employees(Naming): " + n.getMessage());
return null;
}
catch (FinderException f)
{
System.err.println("Error loading Employees(Finder): " + f.getMessage());
return null;
}
As you can see, the local bean has to lookup the EJB slightly differently, even
though they are running in the same container. Also, there is no RemoteException
thrown by the find or the create methods, so the exception does not have to be
caught.
There is one more difference, and that is in the ejb-jar.xml deployment descriptor.
For an EJB to look up a local EJB, it must point to the correct location using an
<ejb-local-ref> tag. If this is not used, the container will not be able to find the
bean. For each EJB that needs to use the local EJB, the XML below must be in the
deployment descriptor.
<entity>
<ejb-name>Dept</ejb-name>
.
.
.
<ejb-local-ref>
<ejb-ref-name>LocalEmp</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<local-home>ejb.cmplocal.EmpHome</local-home>
<local>ejb.cmplocal.Emp</local>
<ejb-link>Emp</ejb-link>
</ejb-local-ref>
</entity>
This example will allow the EJB Dept to call the local EJB Emp using the name
LocalEmp. This is required because EJBs can have both local and remote
interfaces, and to call the EJB Emp via it's remote interface the EJB Dept would
look up the name Emp rather than the local reference LocalHome.
30). How can I call one EJB from inside of another EJB?
In case of Remote :
EJBs can be clients of other EJBs. It just works. Really. Use JNDI to locate the
Home Interface of the other bean, then acquire an instance reference.
For Example : Context ctx = new InitialContext();
//get Home interface of bean
//narrow -retype
EmpHome lhome = (EmpHome )
javax.rmi.PortableRemoteObject.narrow(ctx.lookup("java:comp/env/LocalEmp"),
EmpHome .class);
//get remote interface
Emplbean = lhome.create();
//now you can call bussiness method on remote interface like
lbean.doSomething()
Incase of Local : but we no longer have to worry about the PortableRemoteObject,
as the bean is no longer remote
Context ctx = new InitialContext();
Object o = ctx.lookup("java:comp/env/LocalEmp");
EmpHome empHome = (EmpHome)o;
31). 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-
There are two basic kinds of find methods: single-entity and multi-entity. Singleentity find methods return a remote reference to the one specific entity bean that
matches the find request. If no entity beans are found, the method throws an
ObjectNotFoundException . Every entity bean must define the single-entity find
method with the method name findByPrimaryKey(), which takes the bean's
primary key type as an argument.
The multi-entity find methods return a collection ( Enumeration or Collection type)
of entities that match the find request. If no entities are found, the multi-entity find
returns an empty collection.
3. remove methods: These methods (you may have up to 2 remove methods, or
don't have them at all) allow the client to physically remove Entity beans by
specifying either Handle or a Primary Key for the Entity Bean.
4. home methods: These methods are designed and implemented by a developer,
and EJB specification doesn't have any requirements for them except the need to
throw a RemoteException is each home method.
36). What is the difference between Container-Managed Persistent (CMP)
bean and Bean-Managed Persistent(BMP) ?
Container-managed persistence(CMP) beans are the simplest for the bean
developer to create and the most difficult for the EJB server to support. This is
because all the logic for synchronizing the bean's state with the database is handled
automatically by the container. This means that the bean developer doesn't need to
write any data access logic, while the EJB server is supposed to take care of all the
persistence needs automatically. With CMP, the container manages the persistence
of the entity bean. A CMP bean developer doesn't need to worry about JDBC code
and transactions, because the Container performs database calls and transaction
management instead of the programmer. Vendor tools are used to map the entity
fields to the database and absolutely no database access code is written in the bean
class. All table mapping is specified in the deployment descriptor. Otherwise, a
BMP bean developer takes the load of linking an application and a database on his
shoulders.
The bean-managed persistence (BMP) enterprise bean manages synchronizing its
state with the database as directed by the container. The bean uses a database API
to read and write its fields to the database, but the container tells it when to do each
synchronization operation and manages the transactions for the bean automatically.
Bean-managed persistence gives the bean developer the flexibility to perform
persistence operations that are too complicated for the container or to use a data
source that is not supported by the container.BMP beans are not 100% databaseindependent, because they may contain database-specific code, but CMP beans are
unable to perform complicated DML (data manipulation language) statements. EJB
2.0 specification introduced some new ways of querying database (by using the
EJB QL - query language).
37).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
38). What is bean managed transaction?
If a developer doesn't want a Container to manage transactions, it's possible to
implement all database operations manually by writing the appropriate JDBC code.
This often leads to productivity increase, but it makes an Entity Bean incompatible
with some databases and it enlarges the amount of code to be written. All
transaction management is explicitly performed by a developer.
39). 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.
40). What is the difference between ejbCreate() and ejbPostCreate
The purpose of ejbPostCreate() is to perform clean-up database operations after
SQL INSERTs (which occur when ejbCreate() is called) when working with CMP
entity beans. ejbCreate() is called before database INSERT operations. You need to
use ejbPostCreate() to define operations, like set a flag, after INSERT completes
successfully.
When working with BMP entity beans, this is not necessary. You have full control
over the entire process, so you can place all the necessary logic surrounding your
INSERT statement directly in the ejbCreate() method.
Even if you are creating BMP entity beans, the recommendation would still be to
include an empty ejbPostCreate() method. Although some application servers will
not enforce it, the spec indicates that this placeholder should be there.
41).What is the difference between sessioncontext and entitycontext?
Since EnterpriseBeans live in a managed container,the container is free to call
your EJB components methods at its leisure.
The container houses the information like current status of bean,security
credentials of the user currently accessing the bean in one object is called
EJBContext Object.
A context represents a way for beans to perform callbacks and modify their current
status
SessionContext is EJB context for session bean
EntityContext is EJB context for entity bean
Message driven context is EJB context for message driven bean
42). What is the difference between ejbStore() and ejbLoad()?
ejbStore() will be called before ejbPassivate() and is used to store the object to
persistent database.
ejbLoad() will be called before ejbActivate() and is used to retrieve the object from
persistence datastore.
43). What is the difference between EAR, JAR and WAR file?
J2EE defines three types of archives:
object and leaves others like it unmodified. It is having close similarities like
aspect stuff, but not with EJB stuff.
46). What is lazy loading?
Lazy loading means not creating an object until the first time it is accessed. Lazy
loading typically looks like this:
public class Example {
private Vector data = null;
public Vector getData() {
if (this.data == null) {
this.data = new Vector();
// Load data into vector ...
}
return this.data;
}
}
This technique is most useful when you have large hierarchies of objects (such as a
product catalog). You can lazy-load subordinate objects as you navigate down the
hierarchy, and thereby only creat objects when you need them.
47). What is Message Driven Bean?
An MDB is essentially a message consumer that can listen to a message destination
or a message endpoint and gets activated when a message arrives. By design,
MDBs are anonymous in nature and hence cannot be directly invoked by a client.
The only way to invoke an MDB is to send a message to the destination or
endpoint to which it is listening. As MDBs are stateless in nature and are not
related to any specific client, they can be pooled for concurrent processing of
messages.
48). What is CMR?
CMR is an acronym for Container Managed Relation-ships.
CMR, represented by the cmr fields in the deployment descriptor, which represents
the relationship exists between different entities (entity beans), which are in turn
exhibiting the database to the real world. The relationships are one-one, one-many,
& many-many.
All the relations/ referential integrities will be managed by container, then the
definition's in the deployment descriptor's are called as Container Managed
Relationships (CMR)..
49). Can a Session Bean be defined without ejbCreate() method?
The ejbCreate() methods is part of the bean's lifecycle, so, the compiler will not
return an error because there is no ejbCreate() method.
However, the J2EE spec is explicit:
the home interface of a Stateless Session Bean must have a single create() method
with no arguments,
while the session bean class must contain exactly one ejbCreate() method, also
without arguments.
Stateful Session Beans can have arguments (more than one create method)
50). What are the optional clauses in EJB QL?
WHERE and ORDERBY clauses are optional in EJB QL where as SELECT and
FROM are required clauses.
51). Can I use session beans and hibernate (instead of entity beans) for
persitance?
Yes, we can. It's same as BMP.
52). If session has thrown ApplicaitonException would you use EJBContext.
setRollBackOnly method?
According to the EJB specification, when the ApplicationException is thrown, the
EJBContext.setRollBackOnly method is not called.
Typically, an enterprise bean marks a transaction for rollback to protect data
integrity before throwing an application exception, because application exceptions
do not automatically cause the Container to rollback thetransaction.
For example, an AccountTransfer bean which debits one account and credits
another account could mark a transaction for rollback if it successfully performs
the debit operation, but encounters a failure during the credit operation.
Use remote client view when you need to be sure that parameters passed between
your EJB and the client (and/or other enterprise beans) should be passed "by value"
instead of "by reference." With pass-by-value, the bean will have its own copy of
the data, completely separated from the copy of the data at the client. With local
client view, you can do pass-by-reference, which means your bean, as well as the
client, will work directly with one copy of the data. Any changes made by the bean
will be seen by the client and vice versa. Pass-by-reference eliminates time/system
expenses for copying data variables, which provides a performance advantage.
If you create an entity bean, you need to remember that it is usually used with a
local client view. If your entity bean needs to provide access to a client outside of
the existing JVM (i.e., a remote client), you typically use a session bean with a
remote client view. This is the so-called Session Facade pattern, the goal of which
is that the session bean provides the remote client access to the entity bean.
If you want to use container-managed relationship (CMR) in your enterprise bean,
you must expose local interfaces, and thus use local client view. This is mentioned
in the EJB specification.
Enterprise beans that are tightly coupled logically are good candidates for using
local client view. In other words, if one enterprise bean is always associated with
another, it is perfectly appropriate to co-locate them (i.e., deploy them both in one
JVM) and organize them through a local interface.
57). Why CMP beans are abstract classes?
We have to provide abstract data to object mapping that maps the fields in our bean
to a batabase, and abstract methods methods that corelate these fields.
58). What is the difference between normal Java object and EJB?
Java Object: is a reusable component.
EJB : is a distributed component used to develop business
applications. Container provides runtime environment for EJBs.
59). What is abstract schema?
Abstract schema is part of an entity bean's deployment descriptor which defines the
bean's persistent fields and their relationship. Abstract schema is specifed for entity
beans with container managed persistence. We specify the name of the Abstract
schema name in the deployment descriptor. The queries written in EJB QL for the
finder methods references this name. The information provided in this Abstract
the MDB class to create a new instance. Next, the container calls
setMessageDrivenContext() followed by ejbCreate() on the instance. The bean then
enters the Ready state and is ready to consume messages.
When a message arrives for the bean, the container invokes the onMessage()
method of one of the available instances, passing a Message object in argument.
Message s can be consumed and processed concurrently by using multiple
instances of the same type.
The container invokes ejbRemove() on the bean instance when it no longer needs
the instance. The bean instance can perform clean up operations here.
63). Can an entity bean be a listener for JMS messages?
No. Message driven beans should be used to consume JMS messages.
64). What is Entity Bean. What are the various types of Entity Bean?
Entity bean represents the real data which is stored in the persistent storage like
Database or file system. For example, There is a table in Database called
Credit_card. This table contains credit_card_no,first_name, last_name, ssn as
colums and there are 100 rows in the table. Here each row is represented by one
instance of the entity bean and it is found by an unique key (primary key)
credit_card_no.
There are two types of entity beans.
1) Container Managed Persistence(CMP)
2) Bean Managed Presistence(BMP)
65). What is IIOP ?
It is Internet Inter Object Resource Broker Protocl
66). Why don't stateful session beans have a pool?
Stateful session beans get instantiated once for each seperate client request and it
stores the client information in it, there is no threading concept in EJB hence if
there will be an instance pool will exist then there is a possiblity of information
leak between different session objects.
therefore there is no concept of instance pooling in stateful session bean.
67). Without using entity beans can we do database transactions?
Without using entity beans we can do database transactions through Springs
.Spring can be used to configure declarative transaction management, remote
access to your logic using RMI or web services, mailing facilities and various
options in persisting your data to a database
68). What is the use of using session facade design pattern in EJB'S?
There are many uses, important one is to reduce network traffic I you are calling
many EJB from your Servlet then this is not advised, because it has to make many
network trips, so what you do you call a Stateless session bean and this in turn calls
other EJB, since they are in same container there is less network calls other thing
you can do now is you can convert them to LOCAL EJB which has not network
calls. This increases your server bandwidthJ. Problem solver this is good for a
highly available system.
69). What is the difference between session and entity beans? When should I
use one or the other?
An entity bean represents persistent global data from the database; a session bean
represents transient user-specific data that will die when the user disconnects (ends
his session). Generally, the session beans implement business methods (e.g.
Bank.transferFunds) that call entity beans (e.g. Account.deposit,
Account.withdraw)
70). 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
its read-only in the EJB. If anything is altered from inside the EJB, it wont 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.
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 clients message as the
single argument. The message beans 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.
77).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 beans cache has been cleared, the bean
still takes up some memory just being in the Pooled State.