Question

Question 1

What's difference between Servlet /JSP session and EJB session?

Answer

From a logical point of view, a Servlet/JSP session is similar to an EJB session. Using a session, in fact, a client can connect to a server and maintain his state.

But, is important to understand, that the session is maintained in different ways and, in theory, for different scopes.

A session in a Servlet, is maintained by the Servlet Container through the HttpSession object, that is acquired through the request object. You cannot really instantiate a new HttpSession object, and it doesn't contains any business logic, but is more of a place where to store objects.

A session in EJB is maintained using the SessionBeans. You design beans that can contain business logic, and that can be used by the clients. You have two different session beans: Stateful and Stateless. The first one is somehow connected with a single client. It maintains the state for that client, can be used only by that client and when the client "dies" then the session bean is "lost".

A Stateless Session Bean doesn't maintain any state and there is no guarantee that the same client will use the same stateless bean, even for two calls one after the other. The lifecycle of a Stateless Session EJB is slightly different from the one of a Stateful Session EJB. Is EJB Container's responsability to take care of knowing exactly how to track each session and redirect the request from a client to the correct instance of a Session Bean. The way this is done is vendor dependant, and is part of the contract.

With Stateless - nothing, once it done with your method invocation it's don't care about you. About satefull it’s up to particular app sever implementation/configuration .. Chances are if you hold reference to it in httpsession and it’s get expired (= user will never be able to release this EJB) server eventually will recycle this instance

Question 2

why we use home interface in EJB. In RMI we dont have any concept like home interface. why we particularly go for Home Interface Both RMI and EJB are distributed applications. In EJB we use Home interface which is not avaliable in RMI. There must be several reasons for using Home Interface of EJB. can any one give reason for this?

Answer

By posing this question, you seem to be comparing RMI and EJB as if they were the same type of technology and they are definately not. RMI is a lower level technology that allows java objects to be distributed across multiple JVMs. Essentially, RMI abstracts sockets and inter-JVM communications.

EJB, on the other hand, is a technology built atop of RMI but does so much more than allow java objects to be distributed. It is a framework that allows you to build enterprise applications by (among other things) abstracting transactions, database access and concurent processing.

Having said this, the answer to your question is the following. The home interface is EJB's way of creating an object. Home interfaces act as factories to create session beans and entity beans. These factories are provided by the application container and take care of many low level details. Since RMI is a lower level technology, it does not offer the home interface. You would have to create it yourself.

Although EJB originally started as a technology for remoting, and therefore made use of RMI for containers implementations, the technology has now outgrown its original intent. The introduction of local interfaces geve EJBs a boost for situations where remoting was not necessary, leading to faster intra-VM calls.

Question 3

In a Session Bean, is opening database connection through resource reference the only way to go? I find it very hard. Are there alternatives?

Answer

It is not very hard to use resource reference.
Just declare the resource reference in your ejb-jar.xml file and you are ready to go.

The alternative would be to package the JDBC driver that is required to connect to the database inside your jar file along with the Session EJB and then to load the driver and get a connection from the DriverManager.
This is really not a way to go. There is nothing in the spec that will prohibit this kind of programming but it is really a horrible way of doing things.
In addition, it is much harder than it would be to simply create a resource reference to your data source and get a connection that way.

Question 4

What is the diffrence between ejbCreate() and ejbPostCreate() in EntityBean?

Answer

ejbCreate() is called before the state of the bean is written to the persistence storage (database). After this method is completed, a new record (based on the persistence fields) is created and written. If the Entity EJB is BMP, then this method must contain the code for writing the new record to the persistence storage.
If you are developing an EJB following 2.0 specs, you can have overloading methods in the form of ejbCreateXXX(). This will improve the development so you can have different behaviour for creating a bean, if the parameters differs. The only requirement is that for each ejbCreateXXX() you need to have corrisponding createXXX() methods in the home or local interface.

ejbPostCreate() is called after the bean has been written to the database and the bean data has been assigned to an EJB object, so when the bean is available.
In an CMP Entity EJB, this method is normally used to manage the beans' container-managed relationship fields.

In short:Primary Key is available only after execution of ejbPostCreate(),not after the ejbCreate(). :)

Question 5

Is there some kind of Design pattern which would make it possible to use the Same code base in EJB and non EJB context?

Answer

A good suggestion would be using Delegation

class PieceOfCode {

    public Object myMethod() {}

class EJBImpl ... {

    PieceOfCode poc = new PieceOfCode();

    public Object myMethod() {

        return poc.myMethod();

This should not be a violation of EJB specs, since EJBs can use simple java classes for their use. Think about Dependant Objects and so on.

Question 6

What is the default time for transaction manager? And how to set maximum time(timeout) for transaction?.

Answer

The default time depends on your app server. It is usually around 30 seconds. If you are using bean-managed transactions, you can set it like this:

// One of the methods from the SessionBean interface
public void setSessionContext(SessionContext context) throws EJBException
{
sessionContext = context;
}

// Then, when starting a new transaction
UserTransaction userTransaction = sessionContext.getUserTransaction();
userTransaction.setTransactionTimeout(60);
userTransaction.begin();
// do stuff
userTransaction.commit();

If you are using container-managed transactions, this value is set in a app server specific way. Check your app server's deployment descriptor DTD.

Question 7

How to register a connection to a database with a JNDI name and use the JNDI name specified?

Answer

First, let's say that the way in which you do this will vary depending on whether you are using an Entity Bean or a Session Bean.

The way in which you access your database from an Application Server is vendor specific.
Usually, you define a connection by specifying a JDBCdriver in your Application Server's config file. You supply the driver along with a user/password to your database (although this too is database and driver specific). Once you've done this, your Application Server will automatically register the connection in JNDI and possibly create a pool of connections.
With Entity Beans, you can define which connection you wish to use inside the deployment descriptor. With Session Beans using JDBC, you lookup the name of the connection you've configured with JNDI.

Since much of this is really Application Server dependant, I recommend you look at sample code from your Application Server vendor.

Question 8

The Singleton pattern is not permitted by the J2EE spec, so How can I cache EJB home interfaces across EJBs in my application and avoid having each EJB get its own home interfaces?

Answer

This is one of those grey areas in the J2EE spec. Yes, it's true that theoretically, static objects (hence, singleton patterns) are not permitted. This is because you never know how many class loaders there are in your ejb container - unless you know the inner working of your container. Therefore, the singleton object will be unique in the class loader only. If there are multiple class loaders, your singleton object will exist more than once (1 instance per class loader). However, if you are ready to accept the fact that your ejb stub may be cached multiple times (as much as once in every class loader), the singleton pattern will still work.

In the ejb container's responsibility to cache ejb stubs. However, some implementation of jndi is very slow to lookup. Repeatedly performing jndi lookups can actually slow down your app considerably. In fact, I have written that exact singleton class you are contemplating and this has increased performance.

Question 9

What are the differences between EJB 1.1 and EJB 2.0?

Answer

There are many differences, all of them should give different type of advantages among the previous 1.1 version.

New CMP Model. It is based on a new contract called the abstract persistence schema, that will allow to the container to handle the persistence automatically at runtime.
EJB Query Language. It is a sql-based language that will allow the new persistence schema to implement and execute finder methods.
Local interfaces. These are beans that can be used locally, that means by the same Java Virtual Machines, so they do not requires to be wrapped like remote beans, and arguments between those interfaces are passed directly.
ejbHome methods. Entity beans can declare ejbHome methods that perform operations related to the EJB component but that are not specific to a bean instance.
Message Driven Beans (MDB). Is a completely new enterprise bean type, that is designed specifically to handle incoming JMS messages.

Question 10

What is session facade?

Answer

Session facade is one design pattern that is often used while developing enterprise applications.
It is implemented as a higher level component (i.e.: Session EJB), and it contains all the iteractions between low level components (i.e.: Entity EJB). It then provides a single interface for the functionality of an application or part of it, and it decouples lower level components simplifying the design.

Think of a bank situation, where you have someone that would like to transfer money from one account to another.
In this type of scenario, the client has to check that the user is authorized, get the status of the two accounts, check that there are enough money on the first one, and then call the transfer. The entire transfer has to be done in a single transaction otherwise is something goes south, the situation has to be restored.

As you can see, multiple server-side objects need to be accessed and possibly modified. Multiple fine-grained invocations of Entity (or even Session) Beans add the overhead of network calls, even multiple transaction. In other words, the risk is to have a solution that has a high network overhead, high coupling, poor reusability and mantainability.

The best solution is then to wrap all the calls inside a Session Bean, so the clients will have a single point to access (that is the session bean) that will take care of handling all the rest.

Obviously you need to be very careful when writing Session Facades, to avoid the abusing of it (often called "God-Bean").

Question 11

Session Bean transactions.
Why EJB 1.1 specs says that Session Beans can have BM or CM transaction, but not both in same bean?

Answer

CMTs and BMTs are 2 different animals. Mixing them in the same bean would require the application container to potentially start a transaction at the beginning of the method while the BMT bean itself would start another. Things could get quickly get out of hand.
Even mixing CMT beans and BMT beans in the same process flow can be tricky. For example, a BMT bean cannot participate in transactions started by a CMT bean (although the opposite is allowed).

The real question is why would you need to do this? Most of the time, you will use CMTs. BMTs are used in special circumstances where you need fine-grained transaction control.

Question 12	Are there any tools for porting EJB Applications from one Application Server to another?
Answer	In theory, you should not need any tools for that task if you consider porting from Weblogic to JBOSS from the following location you can download the tools: http://www.jboss.org/services/bea-port.jsp

Question 13

What is passivation and activation?

Answer

Passivation and activation are two phases of a resource management technique that reduces the number of bean instances needed to service all clients. Passivation is the process of disassociating a bean instance from its EJB object so that the instance can be reused or evicted to conserve memory. Activation is the process of associating a bean instance with an EJB object so that it can service a request. Beans are passivated when there is a lull in their use and activated when the EJB object receives a client request.

The java.ejb.SessionBean and javax.ejb.EntityBean interface include two callback methods that notify a bean instance when it is about to passivated or activated. The ejbPassivate( ) method notifies a bean that it is about to passivated; the ejbActivate( )method notifies a bean that it is about to activated.

The mechanisms employed in passivation and activation change depending on the bean type. Stateful beans are usually evicted, while entity beans and stateless beans are pooled. A more detailed account of how different bean types passivated and activated is found under the FAQs for that type.

Question 14

What is passivation and activation?

Answer

Question 15

How does an entity bean obtain a JTA UserTransaction object?

Answer

It doesn't. Entity beans do not employ JTA transactions; that is, entity beans always employ declarative, container-managed transaction demarcation. Entity beans, by definition, are somewhat tightly coupled (via the EJB container and server) to a datastore; hence, the EJB container is in the best position to manage transaction processing.

Question 16

What are the benefits of using a Stateless Session Bean over using a class purely consisting of static methods?

Answer

Mostly container management of transactions and the ability to 'easily' call remote code. Really, the two solutions work at different scales: a Stateless Session Bean is useful when you can define a set of (fairly coarse grained) atomic transactions that are related by a common theme, where a bunch of static methods in a class are more useful for (rather fine grained) utility code.

One common use of Stateless Session Beans is to implement a facade over a set of entity beans, in order to allow the client to be transaction-ignorant. In this pattern the session bean defines a set of transactions that it implements using entity beans. See FAQ question "What is the Session wraps Entity Pattern? What are the motivations behind it?" for more information.

Question 17

Why am I able to call a business method using the same Remote Interface reference after I called the remove() method of a Stateless Session Bean??

Answer

The remove() method on the stateless session bean causes the bean instance to return back to the pool. Now, if you are calling a remote method after the remove, then another instance from the pool will be taken up to service that request. Thus, it appears to the client that the bean was never removed.

However, actually it was returned back to the pool. Also, which bean instance is going to serve that request depends upon the pooling strategy, if its LIFO, the same instance will be serving the request again. As the Specs say: "To the client, it appears as if the client controls the life cycle of the session object. However, the container handles the create and remove calls without necessarily creating and removing an EJB instance."

Question 18

How is Stateful Session bean maintain their states with client?

Answer

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.

Question 19

Life Cycle of Stateful and Stateless Session Beans.

Answer

Stateful Session Bean
A stateless session bean has only two states: Does Not Exists and Method Ready Pool.
A bean has not yet instantiated (so it is not an instance in memory) when it is in the Does Not Exists state.
When the EJB container needs one or more beans, it creates and set them in the Method Ready Pool state. This happens through the creation of a new instance (Class.newInstance()), then it is set its context (setSessionContext()) and finally calls the ejbCreate() method.
The ejbRemove() method is called to move a bean from the Method Ready Pool back to Does Not Exists state.

Stateful Session Bean
Unlike Stateless, a Stateful Session Bean has three states. Does not exists, Method Ready and Passivated states.
Like Stateless beans, when the Stateful Session Bean hasn't been instantiated yet (so it is not an instance in memory) is it in the Does not exists state.
Once a container creates one or more instances of a Stateful Session Bean it sets them in a Method Ready state. In this state it can serve requests from its clients. Like Stateless Session Beans, a new instance is created (Class.newInstance()), the context is passed (setSessionContext()) and finally the bean is created with ejbCreate().
During the life of a Stateful Session Bean, there are periods of inactivity. In these periods, the container can set the bean to the Passivate state. This happens through the ejbPassivate() method. From the Passivate state the bean can be moved back to the Method Ready state, via ejbActivate() method, or can go directly to the Does Not Exists state with ejbRemove().

Question 20

How does passivation work in stateful session beans?

Answer

Unlike entity beans and stateless session beans, stateful session bean are usually evicted from memory when they are passivated. This is not true of all vendors but this view serves as good model for understanding the concepts of passivation in session beans.

When a stateful bean experiences a lull in use -- between client invocations and transactions -- the container may choose to passivate the stateful bean instance. To conserve resources the bean instance is evicted from memory (dereferenced and garbage collected). When the EJB object receives a new client request, a new stateful instance is instantiated and associate with the EJB object to handle the request.

Stateful beans maintain a conversational state, which must be preserved before the bean instance is evicted from memory. To accomplish this, the container will write the conversational state of the bean instance to a secondary storage (usually disk). Only the non-transient serializable instance fields are preserved. When the bean is activated the new instance is populated with the preserved state. References to live resources like the EJBContext, DataSource, JNDI ENC, and other beans must also be maintained somehow -- usually in memory -- by the container.

The javax.ejb.SessionBean interface provides two callback methods that notify the bean instance it is about to passivated or was just activated. The ejbPassivate( ) method notifies the bean instance that it is about have its conversational state written to disk and be evicted from memory. Within this method the bean developer can perform operations just prior to passivation like closing open resources. The ejbActivate( ) method is executed just after a new bean instance has been instantiated and populated with conversational state from disk. The bean developer can use the ejbActivate( )method to perform operations just prior to servicing client request, like opening resources.

Question 21

How does EJB support polymorphism?

Answer

Because an EJB consists of multiple "parts", inheritance is achievable in a rather limited fashion (see FAQ answer on inheritance here). There have been noteworthy suggestions on using multiple inheritance of the remote interface to achieve polymorphism, but the problem of how to share method signatures across whole EJBs remains to be addressed. The following is one solution to achieving polymorphism with Session Beans. It has been tried and tested on WebLogic Apps Server 4.50 with no problems so far.

We will use an example to show how it's done. Say, there are 2 session beans, Tiger and Lion, that share some method signatures but provide different implementations of the methods.

· AnimalHome and Animal are the home and remote interfaces. The signatures of the polymorphic methods are in Animal.

· AnimalBean is the base implementation bean.

· TigerBean and LionBean extend from AnimalBean. They may override the methods of AnimalBean, implementing different behaviors.

· Deploy Tiger and Lion beans, specifying AnimalHome and Animal as their home and remote interfaces. Note that Tiger and Lion should have different JNDI lookup names.

Question 22

How does EJB support polymorphism?

Answer

We will use an example to show how it's done. Say, there are 2 session beans, Tiger and Lion, that share some method signatures but provide different implementations of the methods.

· AnimalHome and Animal are the home and remote interfaces. The signatures of the polymorphic methods are in Animal.

· AnimalBean is the base implementation bean.

· TigerBean and LionBean extend from AnimalBean. They may override the methods of AnimalBean, implementing different behaviors.

· Deploy Tiger and Lion beans, specifying AnimalHome and Animal as their home and remote interfaces. Note that Tiger and Lion should have different JNDI lookup names.

Answer

1) Is method overloading allowed in EJB?

Yes you can overload methods.

2) How can I access my EJBs from COM environments such as VB?

JIntegra.

3) 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.

4) How do you configure the transaction characteristics for a session bean with container-managed transactions?

You must set trans-attribute in the deployment descriptor.

5) How do you configure a session bean for bean-managed transactions?
You must set transaction-type in the deployment descriptor