Top Most Ejb

Top Most What's difference between Servlet/JSP session and EJB session

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.

Container View Point :
1. Servlet Container

• A HttpServlet.service() represents a client thread.
• A logical session is maintaied per such different client threads.The container manages the association rather then the Servlet.Hence Servlet from the pool of servlet instances are reusable for different threads and can be swaped in between client threads.This is why Servlet Instance variable are not thread-safe.

2. EJB Container : Stateful Session Bean.

• The Stateful Session Bean LOGICALLY is a "client thread with State".This thread can be Activated/Passivated as per the situation.But during this 
• activation/passivation essentially the state is saved plus anything else instructed by the bean developer in respective methods.
• In other words the state mangement control is available to 
• Bean developer also.This is what missing in servlet.In other words for Stateful Session Bean instance variable are thread safe.

Designers Perspective :


1. Servlet
Helps the session management but the servlet developer needs to invoke SessionManagement API to read/write.Right candidate for UserInfo,AuthInfo etc.

2.SFB
A well designed component for the stateful processes.
An object state is automaticaly managed by container.Thread-saftey is guranteed.Developer need not to bother.Right candidate for Order/Shopping Process.
Performance wise it is a FEELING that SFB are slower then simple http sessions.Hence needs to be used with care.

Top Most 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. 

Ans:2. 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. 

 In view of this departure form the remoting nature of EJBs, I do believe that the real defining feature of EJBs is the life cycle management provided by the application server. In recent years, the JVM itself has received many improvements in the area of memory management and garbage collection. Sun and IBM have both studied carefully the usage patterns on the servers and built agressive optimization strategies. 

 Marc Fleury (the vibrant voice behind JBoss) recently published an interesting white paper about the optimizations built into modern EJB containers, as well as an interesting view (I happen to share it) that with the flexibility introduced by CMP 2.0, EJB containers are rapidly becoming elaborate caches. These caches keep the raw database data in a format directly usable by Java code, taking care of synchronizing memory and database when necessary.