Stateless Session Bean vs Stateless Singleton

3
votes

I am new to EJBs and recently started working on EJBs (3.0). I have been using Java for 6 years but never worked with EJB's before. I am overwhelmed with the complexity of the whole EJB business to say the least. I fail to understand where I can practically apply some of the concepts.

One question which comes to my mind after understanding the Stateless session bean is, Can you not always replace a stateless session bean with a shared instance of a class with no local members (effectively making it stateless)? I read about instance pooling being done for stateless session beans. If there is no state, can you not simply use one instance?

I am deploying my samples on OpenEJB and one place where I had to use stateless session bean was to interact with the EntityManager. I am not sure if I can get handle to the EntityManager in an arbitrary class. Apart from that, still puzzled what problem stateless session bean tries to solve.

3
javajakarta-eeejbejb-3.0openejb
I think this is debatable, but can I not always replace EJB's with something like Spring and also reduce the immense complexity? What I am figuring out is that what I write is not necessarily as-is portable to some other app server. I ran into various issues to get a simple Entity bean working with Hibernate as JPA in Geronimo, TomEE, GlassFish and JBoss. Could only get it working with JBoss without much of an issue. The problem primarily seamed to be with loading Hibernate Jars which were packaged in WEB-INF/lib/ – Kalpak Gadre

3 Answers

10
votes

A stateless session bean may have state. But it may not have conversational state. So it's perfectly acceptable that a session bean method does the following (although bad practice):

public void foo() {
    this.someVar = bar();
    this.someOtherVar = baz();
    zing();
}

Besides pooling, the EJB container provides several services with stateless beans:

  • dependency injection
  • declarative transaction demarcation
  • declarative security
  • access to the EJB context
  • etc.

So a stateless session bean is much more useful than a simple stateless singleton.

4
votes

No, stateless session beans can have state but that state is not being persisted/bound to a session. Part of that state are injected EJBs or other POJOs which could be stateful beans etc. Thus you need a stateless session bean per request.

In contrast you have a stateful session bean exlusively for one user session and thus that state is bound to the session.

0
votes

You can handle the EntityManager in an arbitrary class but the real problem is how you want to architect your solution.

Except the EJB complexity using EJBs give you a more scalable solution.

As stated before EJB are useful when you are developing a transaction based application. Application server gives you some facilities that are transaction management, EJB pooling, security and so on.

Of course you can implement every thing with a "shared class" but why do you want to re-invent the wheel when you have already everything free?

Stateless session beans are used to implement the business logic the core part of your application. In a Java EE tiered architecture you have 3 tiers: 1. Presentation 2. Businness 3. Data

EJB plays an important role in the Businness logic. You have two choices SLSB and SFSB. The first one are more scalable and are pooled by the Application Server but can't keep their state. The second are less scalable and there's one SFSB for each client session. They are used when you have to hold a conversation between the client the business logic, for example an operation that can't be completed in only one method call to the SFSB. SLSB and SFSB can hold the reference to the EntityManager to manage the entity persistence even if i suggest you to use only SLSB to manage the persistence. EJB3 and JPA is a great solution. Hope this help you