Clean code, stateless session beans and private state

Question

According to clean code by Robert C. Martin methods should have a small signature. The best case would be a method with no parameters at all. Instead it is recommended to use state variables. This is really useful. But what about stateless session beans?

The name is kind of confusing because SLSB can have state. You just have to do your housekeeping so you don't use state from the previous EJB call.

Getting back to clean code: I'd love to use instance variables in SLSBs too. This works fine and if you're careful enough you don't have any trouble with state inconsistencies since the state is overwritten on each public method call.

So far so good. But what happens if a used bean goes back to the pool? It takes its state with it. Depending on the size of the state this could be a real memory leak. JBoss is very generous with beans and generates quite a bunch of them causing some serious memory consumption - for nothing.

So one way would be to clean up the state before the bean method exists and the bean is returned to the pool. But this seems to me like useless code that should be avoided.

Is there a proper way to deal with this problem? What's the best practice in this situation?

Answer 1

It's perfect possible to keep instance variables in SLSB, since you don't use the proxy do make calls between methods. For instance:

@Stateless 
public class MyEJB {
    private String myVar;

    public void receiveVar(String myVar) {
        this.myVar = myVar;
        useVar();
    }

    private void useVar() {
        // do something with var
    }
}

The point is: when you inject this SLSB in another, any method call will pass through the proxy to achieve the actual EJB. So, considering that the real instance is retrieved from the pool when the method is called on the proxy instance, there's no guarantee that the proxy will use the same pooled instance between two or more calls. So isn't possible ensure the value of any declared class attribute.

When the SLSB backs to the pool, it take with itself every setted value (I think it may change according the vendor, I'm not really sure). But, it's completely possible (and acceptable) that a pooled SLSB instance already has a previously configured attribute value.

I didn't understand your point here:

So far so good. But what happens if a used bean goes back to the pool? It takes its state with it. Depending on the size of the state this could be a real memory leak. JBoss is very generous with beans and generates quite a bunch of them causing some serious memory consumption - for nothing.

Do you have any example of "big state" you could have in a SLSB?

And finally:

I think the best way to handle the values is always handle state variables that you'll use. Setting before and cleaning after use. And the best practice is avoid this kind of confusing situation.

Hope it helps.