21). What is the difference between Stateful session bean and Stateless 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 passed to the client.
An EJB has a remote interface and a home interface, with the exception of MessageDrivenBeans. The remote interface extends the interface javax.ejb.EJBObject and the home interface extends the interface javax.ejb.EJBHome. The EJB is accessible from any client, in any JVM, provided they have the proper authorization.
For example, the Home and Remote interfaces of an EJB called EMP may look like this.
Remote:
public interface Emp extends EJBObject
{
long getEmpno() throws RemoteException;
void setEmpno(long newDeptno) throws RemoteException;
String getEname() throws RemoteException;
void setEname(String newDname) throws RemoteException;
Home:
public interface DeptHome extends EJBHome
{
public Emp create() throws RemoteException, CreateException;
public Dept findByPrimaryKey(DeptPK primaryKey) throws RemoteException, FinderException;
Note that both the home and the remote interface throw a RemoteException in all of their method definitions. The ejb-jar.xml deployment descriptor for these EJBs would look something like the snippets below:
<entity>
<ejb-name>Emp</ejb-name>
<home>ejb.cmplocal.EmpHome</home>
<remote>ejb.cmplocal.Emp</remote>
<ejb-class>ejb.cmplocal.EmpBean</ejb-class>
.
.
.
Local BeansThe EJB 2.0 specification standardize a means of making local connections to EJBs with Local Interfaces.
For an EJB to be classed as a local EJB, it must implement the local versions of the home and remote interfaces, javax.ejb.EJBLocalObject for the Home interface, and javax.ejb.EJBLocalHome. For a client to call the Local interface, they must be running in the same JVM as the JVM that the EJB exists in. This means that not only an EJB can call a local EJB , Servlets or JSPs can also call the EJB via it's local interface if they are packaged together as part of same application.
For example, the LocalHome and Local interfaces of an EJB called EMP may look like this.
Local:
public interface Emp extends EJBLocalObject
{
long getEmpno();
void setEmpno(long newEmpno);
String getEname();
void setEname(String newEname);
LocalHome:
public interface EmpHome extends EJBLocalHome
{
public Emp create() throws CreateException;
public Emp findByPrimaryKey(EmpPK primaryKey) throws FinderException;
The ejb-jar.xml deployment descriptor for these EJBs would look something like the snippets below:
<entity>
<ejb-name>Emp</ejb-name>
<local-home>ejb.cmplocal.EmpHome</local-home>
<local>ejb.cmplocal.Emp</local>
<ejb-class>ejb.cmplocal.EmpBean</ejb-class>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>Emp</abstract-schema-name>
.
.
.
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;