Geek Answers Handbook

Java, beanless session

A standing beans session does not support state. Does this mean they should not have instance variables?

Thanks,
Roger

+4
source share
4 answers

The term “condition” is not misleading in this context. What he means is the dialog state, that is, if the client makes several calls, the bean session does not know. Imagine a sequence of calls:

  • reserveSeatsOnFlight() ;
  • chooseMealPreference() ;
  • confirmBooking() .

You have a dialog state, that is, the second call must be made in the same bean as in the first call, or it just does not make sense. What the session does with the beans state.

A stand-alone beans session may have instance variables, but they are essentially global. If you have a session pool without beans state (which you may or may not depending on what the container decides to do), these instances may or may not exist from one call to another. Therefore, usually avoid instance variables. There are other mechanisms for this kind of thing.

Let me give you an example. Imagine this call in a non-bean session:

 public void bookFlight(List<Passsenger> passengers, FlightNumber flight, Date date) { ... }

if you enter an instance variable to count the number of orders and increase it with each call, subsequent calls may cause different beans, so different values ​​will be displayed. What I mean does not necessarily make sense.

So, returning to the first example, one way to deal with this would be to pass the state to the caller:

 public interface ReservationSystem { public int createNewBooking(); public int reserveSeatsOnFlight(int bookingId, int seats); public int chooseMealPreference(int bookingId, ...) ... }

See how the above no longer has a dialog state? Ok, but it is now encapsulated in the bookingId that you are going through. A session without a bean state can receive an order and continue from where it was not yet.

+9
source

I often saw a stateless beans session, using local variables as a way to maintain a "global" state in a bean (to avoid the burdensome task of passing data from one method call inside an object to another).

Having said that, these are, in fact, global variables in your object and offend themselves (as it was in most cases, which I saw also). I would recommend avoiding them.

There may be times when they are useful, though ... do you have specific information about yourself?

+1
source

A Stateless bean can have instance variables, such as any other object. He simply cannot use them to maintain client-specific values ​​...

+1
source

How about having finite instance variables that are initialized when SLSB starts (i.e. in the constructor). I am thinking of a DAO attribute that is created in the SLSB constructor, for example:

  @Stateless public class MyStatelessBean() { private final CustomerDAO customerDAO; public MyStatelessBean() { // Initialization code goes here this.customerDAO = new CustomerDAO(); } ... }

Thus, a DAO can be used directly in SLSB methods and should not be created every time a DAO is matched. Of course, the DAO is stateless, which is usually the case. Of course, database connections will be provided upon request and will never be stored in the SLSB itself.

0
source

More articles:


All Articles