0

I've wrote stateful session bean:

@Stateful
public class SessionBean {
List<Integer> list = new ArrayList<>();
public void addItem(int s) {
    list.add(s);
}
public int getItemsCount() {
    return list.size();
}
}

and use it in my servlet:

@WebServlet("/add")
public class AddServlet extends HttpServlet {
@Inject
SessionBean sessionBean;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    int i = sessionBean.getItemsCount();
    resp.getWriter().write(i + " ");
    sessionBean.addItem(i + 1);
}
}

It works as expected, list saves the state and I can use it in next request. But if I'd change @Stateful on @Stateless I expected not to store state of the bean, and get in each request clean list, but it always save the state of previous request and shows new number. So what is the difference between stateless and stateful? How to see it? As I see, they work the same. I want to see example that will show something like - here we use stateful and it saves the state, and here we change on stateless and it works differently and not save the state. Please show me the differences.

Cœur
  • 37,241
  • 25
  • 195
  • 267
user769552
  • 179
  • 1
  • 3
  • 10
  • The web servlet is storing the state of the session bean. If you need a new `SessionBean` for each session, you have to manually create it and store it in a http session. Refer to [this thread](http://stackoverflow.com/questions/19946348/using-stateful-session-beans-with-servlets) for more information. – Jure Kolenko Apr 19 '17 at 13:47
  • Have seen some cases in which a SLSB behaves like a SFSB. I.E SLSB injected into a singleton. In this case the same instance of the SLSB have been used. I believe that in your case also, the same bean instance has been reused from the pool. Have your tried it with multiple concurrent invocations of the servlet URL? I believe that if you do so, this pseudo-stateful effect will cease to appear. – garfield Apr 20 '17 at 10:34

2 Answers2

2

But if I'd change @Stateful on @Stateless I expected not to store state of the bean, and get in each request clean list, but it always save the state of previous request and shows new number.

The Stateful vs. Stateless distinction is foremost declarative, not functional. If you declare a session bean to be stateless, then it is your responsibility to ensure that it does not actually retain any state between method invocations.

So what is the difference between stateless and stateful? How to see it? As I see, they work the same.

One of the more important differences is that if you declare a bean stateless then you afford the container the option of serving different requests with different bean instances. If it opted to do so then that could make a declared-stateless bean that in fact retains state appear not to retain state after all, at least to a limited extent. But the container is not required to do that, so if your stateless bean violates its contract by retaining state, then that will probably be visible to clients sooner or later.

There is more (rather a lot more, in fact -- read the specifications), but the most important thing is what I led off with. To put it another way, the correct declaration of a session bean as stateless vs. stateful is part of its developer's contract with the container in which it is deployed. A bean does not behave differently than its code demands just for being declared stateless.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • Well, there are some cases in which the bean behaves differently, for example with a stateless using BMT you are obliged to commit a transaction before the method return, while a stateful can leave the transaction open and commit at a later stage within a completely different method. – Leonardo Apr 20 '17 at 09:30
  • That's a fair point, @Leonardo. It is also entirely consistent with this answer, which makes no attempt to enumerate all the differences between stateless and stateful beans, and indeed expressly observes that there are other differences. – John Bollinger Apr 20 '17 at 16:18
1

Stateless session beans are not expected to carry any form of state, e.g. instance variables. Therefore, containers often maintain a pool of stateless beans so they can be reused by different clients.

The Oracle doc mentions the following about session beans: http://docs.oracle.com/javaee/5/tutorial/doc/bnbly.html

Clients may, however, change the state of instance variables in pooled stateless beans, and this state is held over to the next invocation of the pooled stateless bean.

This phenomenon is what you might be experiencing and why the list not empty.

Luciano van der Veekens
  • 6,307
  • 4
  • 26
  • 30