distinctions between Stateless and Stateful bean

[Goran Markovic]

Hi, I have already touch this issue, but I really do not get it as clear as I need. Here I will interpret my point of vies of session bean. The real question is about why to use certain bean ( according to specific practical reason) and what id the differences between them.
Stateless beans: are pooled from been pool, lifecycle is confine at one request, and after job is done, they are return to pool. (Setting pool size and another config. is about another issues)
Stateful beans: are created one per user, and used through application until @Remove annotated method is invoked or after container specific idle time expire.
I do not get it what is the difference between these sessions, if it's only based on performance?
The satateful bean is used to 'maintain users conversation state'. Considering that users state in web tier is managed through HttpSession (through an ID correctly), does it measn when I pass some object from web tier to ejb, sesion id is passed too?
Or, when it said that stateful beans are used to maintain conversational state it mean only a rhetorically right? there is no some kind of id-trasmission between web tier and ejb tier, or it does? Dows Statefull beans have principle of storing some kind of HttpSession passed by web tier (if it does I donot see purpose of it).
If communication occurs mediating through web tier, user conversational state is maintained through HttpSession, only?!?!
I mean it's really confusing to me.
We can use Statless bean with session facade in web tier, where we have an instance of stateless bean, and that instance invoke some method, inside what are encapsulated some business methods.
Another way is using a stateful bean, inside what are declared business method, and use them. As I see (neglecting performance issues) the result is the same, except in case of stateless bean we have a one additional call.
And here I come to conclusion (if my exposed opinion is correct) that only lyfecycles and performance issues, are peculiarities what make distinctions between these two beans.
I'll be grateful if some one give me big pics (just logical pint of view) about that issues. Thanks!

[Paul Sturrock]

I do not get it what is the difference between these sessions, if it's only based on performance?

What sessions? Only one type of bean has a "session" in reality: the stateful session bean.

The satateful bean is used to 'maintain users conversation state'. Considering that users state in web tier is managed through HttpSession (through an ID correctly),

What would you use if there were no web tier?

does it measn when I pass some object from web tier to ejb, sesion id is passed too?

No. You should think of HttpSession and EJBSession as unrelated things. Though both relate to the current user, neither relate to each other. They probably both exist in one application server but they may not. And an EJB may be being used by a non-web client.

Or, when it said that stateful beans are used to maintain conversational state it mean only a rhetorically right? there is no some kind of id-trasmission between web tier and ejb tier, or it does? Dows Statefull beans have principle of storing some kind of HttpSession passed by web tier (if it does I donot see purpose of it)

No you cannot pass the HttpSession to an EJB session, though you can pass any data contained in the HttpSession. Like I said before, what would you use to store conversational state if there were no web teir?

If communication occurs mediating through web tier, user conversational state is maintained through HttpSession, only?!?!

No. If you use an HttpSession and a stateful session bean there are two caches of conversational state, one in the servlet container the other in the ejb container. Why would you do this? Imagine your web application is only one of a number of client applciations to your EJB.

We can use Statless bean with session facade in web tier, where we have an instance of stateless bean, and that instance invoke some method, inside what are encapsulated some business methods.

Well, you can use a stateless session facade from the web tier (it exists in the EJB tier).

And here I come to conclusion (if my exposed opinion is correct) that only lyfecycles and performance issues, are peculiarities what make distinctions between these two beans.

Sort of. The big differernce is the different functionality provided by the two. The extra behaviour a stateful session bean provides will also (probably) a negative effect on the performance of your application. Its harder for example to distribute EJB instances that have state.

[Goran Markovic]

Paul
Thanks you on comprehensive answers, but let redefine my question :
What do I need ejb for, if :
I can use Hibernate as persistence layer.
What for I need Statless or Stateful beans, when I can use ordinary methods in my model classes(ordinary beans), where I would perform some logic.

we have a code:

public interface UserManager {
public Long manageUser(User user);
}

@Stateful
public class UserManagerBean implements UserManager{
public Long manageUser(User user){

// here I will not introduce follow methods but it's name will depict their purpose
checkUserId(user.getSecretId());
signThe user(user.getUserName());
return persistUser(user); // this method will involve persistence layer, EntityManager and database comunication...
}
// rest of methods ...
.
.
.

public class Test extends HttpServlet {
public void doGet( HttpServletRequest req, HttpServletResponse res) throws ServletException {
String userName = req.getParameter("username");
String password = req.getParameter("password");
Integer secretId = Integer.parseInt(req.getParameter("id"));
User user - new User(userName, password, secretId);

@EJB // Injecting steteful bean
private UserManager um;
um.manageUser(user);
}
}

So here we collect information from presentation layer, and from servlet call business tier, who on the other side communicate with persistence tier. Our spot is on presentation tier (servlet) and business tier (ejb). What do we get here by involving EJB?
We could also include some ordinary beans (model classes) where business logic reside in and that classes to communicate with persistence provider (just as we do in web application deployed on web container), instead of Stateful and Stateless beans (MDB I found very powerful and practical, but here my focus is only on Stateful and Stateless beans).
So, the final question is : what are the benefits from Stateful and Stateless beans, which cannot be accomplished my model-business classes from web tier?
I hope I was quite understandable in order to get precious answer (and not an anger of folks because of my exhaustive questions :-) ).

[Reza Rahman]

Slobodan,

What EJB 3 reference are you using, if any? Most should provide answers to these questions? We certainly do in EJB 3 in Action. If you happen to own it, I can refer you to the relevant sections and try to save myself some time.

If no one else responds, I'll can repeat some of that material here again the best I can. I think these questions might be a little on the basic/broad side for folks to answer reasonably and do justice to the topic.

Cheers,
Reza

[Jeanne Boyarsky]

Slobodan,
You don't need EJB. EJBs are useful if you want to use container managed services - like security, cloning/failover, etc.

[Reza Rahman]

Jeanne is exactly correct. You don't "need" EJB. However, if you do need container services you will wind-up reinventing the code to do it (probably in more complex ways) or use an alternative technology that mirrors EJB functionality (such as Spring). Here is a fairly comprehensive list of the container services that EJB offers:

1. Dependency injection of EJB and managed resources such as data sources, queues, topics, entity managers, entity manager factories and JavaMail sessions
2. Dependency injection of EJBs into Servlets and JSF backing beans.
3. Declarative and programmatic transactions
4. Declarative and programmatic security
5. Transparent integration with JPA, including support for container managed entity managers with transaction or extended scope persistence contexts
6. RMI-based remoting
7. Web services via JAX-WS
8. Interceptor based AOP
9. Scheduling
10. Business tier state management including passivation
11. Messaging
12. Pooling, band-width throttling
13. Clustering, load-balancing, replication
14. Thread-safe components
15. Caching

In your case, I think the obvious services would be DI, transactions and JPA support that you won't get as easily with non-managed POJOs. You may or may not also need server-side state with passivation, the extended persistence context, caching, pooling, clustering and thread-safety. One of the most common pitfalls of folks trying to use JPA without EJB 3 or Spring is the fact that the JPA entity manager is not thread-safe: https://blueprints.dev.java.net/bpcatalog/ee5/persistence/webonlyapp.html.

As to the question of maintaining state in just the HTTP session, while it is possible, there are a few problems:

1. You will wind-up making your business tier code very dependent on the HTTP session. Architecturally, this violates the principle of tier separation.
2. You will likely wind up managing a lot of smaller pieces of data into the HTTP session as opposed to simply saving a stateful session bean reference and managing state more naturally in stateful bean instance variables.
2. Your session data may be replicated just like stateful beans, but they won't be passivated.
3. You won't be able to utilize the extended persistence context.

As to using Hibernate natively instead of through JPA, there really isn't a reason to do it. In fact, the major feature for Hibernate 3 was supporting JPA 1.0, including annotations. In fact, native Hibernate has no separate annotation support and is dependent on JPA annotations. All of my customer have stopped using Hibernate directly after Hibernate 3.0 and use JPA instead. Using JPA also means that you can swap out persistence providers when you want to. For example, some of my customers use Hibernate for development and TopLink in production.

Let me know if you need clarification on any of the above. Again, all this is in EJB 3 in Action.

Hope it helps,
Reza

[Goran Markovic]

Thanks Reza, I have been studied from EJB 3 in Action so far.And pretty much I understand lot of things, also JPA because I was familiar previously with Hibernate.
However I believe that preceding jndi issue need some clarification, so I'm gonna update 'jndi issue' title with my question.

[Reza Rahman]

Slobodan,

OK that definitely makes life easy on my end, I'll just refer to the book sections. Please do make a more specific post and I will answer it. Example code will help a great deal, along with the question.

Proper JNDI coverage was something we had to fight hard with the publisher on. The Publisher wanted to avoid JNDI altogether, primarily because they were listening to a group of Spring fanatics without a balanced understanding of Java EE. We tried to point of that most Spring books cover the Spring application context and look-up, but even that fell on deaf ears. We are fighting this battle again on the second edition. Hopefully this time we will win...

Thanks,
Reza

[Goran Markovic]

Hi Reza, I have specified a question in the topic 'jndi issue' (in order to not blend topics), so if you do not mind, my question is out there and most of question is my understanding of certain issue, waiting for conformation of them

[Reza Rahman]

Slobodan,

OK, I'll take a look ASAP. Thanks for the efforts at being a good online citizen.

Cheers,
Reza

[Goran Markovic]

Thanks Reza. I'm looking forward to you answer about 'jndi issue' title, so I could as soon as possible take a SCBCD exam.