What is the point of having global variable in a Stateless Session Bean?

Question

We know Stateless Session Beans do not hold state by any means. Then what is the point of having a global variable in a Stateless Session Bean? Why it is not blocked in the specification (to avoid unnecessary confusion)?

If there are any practical benefit of having global variable, please explain with a piece of code fragment.

Agrostology

Define "global variable"; I ask because it's not a standard Java term, and may mean different things to different people. – Wisconsin

Answer 1

A quote from the EJB 3.1 spec

4.7 Stateless Session Beans

Stateless session beans are session beans whose instances have no conversational state. This means that all bean instances are equivalent when they are not involved in servicing a client-invoked method.

The term “stateless” signifies that an instance has no state for a specific client. However, the instance variables of the instance can contain the state across client-invoked method calls.

Examples of such state include an open database connection and an object reference to an enterprise bean object.

The emphasis is on no conversational state. They can have "other" state.

---

For example, I have used it to check if the load was spread equally over all instances in a cluster node:

@Stateless(name = "DemoPingSb")
@Remote(DemoPingSbIfc.class)
public class DemoPingSb implements Serializable, DemoPingSbIfc {
    private final AtomicInteger instancePingCount = new AtomicInteger(0);
    private final static AtomicInteger classPingCount = new AtomicInteger(0);

    public DemoPingSb() {
        super();
    }

    public String ping(final String s) {
        final int local = this.instancePingCount.incrementAndGet();
        final int global = classPingCount.incrementAndGet();

        System.out.println("INFO: local " + local + ", global " + global
                + ", s " + s);

        return s.toUpperCase();
    }
}

and if there is enough load:

13:13:21,769 INFO [stdout] (http-localhost-127.0.0.1-8080-1) INFO: local 22, global 22, s hello
13:13:21,936 INFO [stdout] (http-localhost-127.0.0.1-8080-1) INFO: local 1, global 23, s hello

So there are some special cases where this feature might be useful.

Remarks

• The spec talks about instance variables; the usage of a static variables is not covered there. So the code might not be correct regarding classPingCount
• The usage of an AtomicInteger for instancePingCount could by replaced with volatile int, because (4.10.13)

The container must ensure that only one thread can be executing a stateless or stateful session bean instance at any time.

• A stateless session bean is never passivated (4.2)

Shrove

Answer 2

Clearly any answer must state that a stateless session EJB must not hold state between calls to methods on the EJB.

Rather than take a hard-line approach by forbidding instance variables in an EJB, the EJB developer is allowed to define them for intermediate storage. Perhaps there are intermediate values, and internal private methods are being invoked; rather than passing parameters and/or creating a "immediate state object" to be passed for the short term, a developer (arguably lazy) may just use instance variables.

The key here, which is addressed by the spec, is that in no circumstances should the EJB developer assume that any such field would maintain meaningful information across invocations of the EJB.

Wisconsin

Regarding the last quote: Could you please add the version and the paragraph of the spec you have quoted from. – Shrove

@Shrove I was attempting to stress the point, not quote anything directly. I see you've provided a relevant quote - that's great. "Conversational" is exactly the point (and the spec wording!) I was attempting to make. – Wisconsin