6

I am reading Java EE7 documentation and here is what it says for stateless bean. I am confused with what is meant by the statement marked in bold below

A stateless session bean does not maintain a conversational state with the client. When a client invokes the methods of a stateless bean, the bean's instance variables may contain a state specific to that client but only for the duration of the invocation. When the method is finished, the client-specific state should not be retained. 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. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client. That is, the state of a stateless session bean should apply across all clients.

However from this post, instance variables in stateless session beans

A stateless session bean is an object that does not have an associated conversational state, but may have instance state. It does not allow concurrent access to the bean. The contents of instance variables are not guaranteed to be preserved across method calls. All instances of a stateless session bean should be considered identical by the client.

I feel that there is a contradiction here. The docs claim (from my understanding) that the instance variable state is preserved across next invocations while the latter post claims there is no guarantee that the state is preserved.

please explain

P.S: I did read this post: but I did not grasp the answer

instance variables in stateless session beans

EDIT form the SO post above

Stateless Session Beans (SLSB) are not tied to one client and there is no guarantee for one client to get the same instance with each method invocation (some containers may create and destroy beans with each method invocation session, this is an implementation-specific decision, but instances are typically pooled - and I don't mention clustered environments). In other words, although stateless beans may have instance variables, these fields are not specific to one client, so don't rely on them between remote calls.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
brain storm
  • 30,124
  • 69
  • 225
  • 393
  • Yes. It's trying to say you can use instance state (applicable to all clients), but not session state (applicable to one client). Any client can get any instance from the bean pool (say a client calls a method twice, that might go to two different instances). – Elliott Frisch Oct 10 '14 at 22:40
  • @ElliottFrisch: according to this post, different clients may see different instance states in stateless bean, http://stackoverflow.com/questions/2351220/stateless-and-stateful-enterprise-java-beans. But the docs claims, state is preserved till next invocation – brain storm Oct 10 '14 at 22:44
  • Different clients may be attached to different nodes in a cluster, what exactly are you wanting to understand? State is preserved *during* the invocation. – Elliott Frisch Oct 10 '14 at 22:45
  • The SO post claims there is no guarantee between different invocation of @stateless bean for the state to be preserved. But the docs link I provided above, seems to convey that instance variable state is preserved. – brain storm Oct 10 '14 at 22:47
  • I suspect you're confused by two *distinct* things called [session(s)](http://stackoverflow.com/a/8889612/2970947). – Elliott Frisch Oct 10 '14 at 22:51
  • Thanks for pointing the link which I have read many times. I dont think I am confused with sessions. In fact, the question here is not about sessions. It is only about stateless beans and what does the statement I bolded above literally mean. – brain storm Oct 10 '14 at 22:53
  • 1
    If you have an instance variable, and you modify it then the modification is persistent across *every **future*** client invocation *except*; If you restart the application server then it will revert. If you redeploy the application then it will revert. If you want different clients to see different instance variables, they won't. – Elliott Frisch Oct 10 '14 at 22:59
  • 1
    @brainstorm I agree, the statements are confusing. I think the difference may be to do with client state and component state. Client state will not be retained between invocations whereas component state (state which is private to the bean) can be and can be modified by a client. I think the top answer on this post may shed some light for you: http://stackoverflow.com/questions/134791/why-pool-stateless-session-beans – JamesB Oct 10 '14 at 23:03
  • @ElliottFrisch: I have posted a block from SO post which claims (in my understanding) that it is not guaranteed to reflect the change across multiple clients.. – brain storm Oct 10 '14 at 23:04
  • Correct. It depends on implementation, and the state that's modified. Beans are (usually) instantiated in a pooled state and instance references are handed out to clients. The server may activate or passivate a bean instance at any time, and applications may be re or un-deployed. – Elliott Frisch Oct 10 '14 at 23:08
  • so the point is does each of the instance references "see" the change made by one client to one instance? Apparently, it is not guaranteed that they all see in case of STATELESS bean.. – brain storm Oct 10 '14 at 23:11
  • @JamesB: the link provided is a good read, though totally not answering my point.. – brain storm Oct 10 '14 at 23:11
  • @brainstorm Fair enough, I disagree, I think it does answer your question to some degree. – JamesB Oct 10 '14 at 23:23
  • So do you understand the distinction now @brainstorm? – kolossus Oct 11 '14 at 06:20

1 Answers1

10

  1. SLSBs are usually created in multiples and are stashed in a pool. So for an EJB UserDataService, there'll be a number of instances created and pooled

  2. When a client requests the services of UserDataService, the container is going to serve one of the pooled instances. Any one. When two clients request the services of the same EJB, there will be two separate instances served

  3. When a client is done with an SLSB, the instance that was in use is usually returned to the pool, not destroyed. What this means is that the same unique EJB objects that were created on container startup could quite conceivably live on the heap for the duration of the container's uptime. That bears repeating: The same SLSBs that were created and pooled when the container first put the EJB into service, are kept alive through the uptime of the container

  4. What (3) means is that if a client in (2) set any variables on the instance of the EJB that it acquired from the pool and that EJB is put back into the pool, the next client that acquires that very instance will be able to see the change made to the state of that EJB (Recall that there is a (sort of) fixed number of instances of the EJBs in the pool and they are cycled among various clients requesting service).

  5. There's no guarantee which specific instance of UserDataService a requesting client will get. There's no guarantee that the client in (2) will get the same instance of UserDataService on two separate requests for that EJB. This is what is meant by no conversational state. You're not guaranteed to be talking to the same instance of that EJB over multiple invocations. This doesn't mean that the EJBs are destroyed mid request, just that in the process of cycling, you cannot be sure of what instance your client will be relating with

kolossus
  • 20,559
  • 3
  • 52
  • 104
  • 1
    ok so the point is the changes made to state to ONE INSTANCE is held over to the next invocation of SAME INSTANCE. But the change is not reflected over all instances in the pool. and hence there is no guarantee that you will get see the same INSTANCE next time you make the call correct? Does proxy plays any part here? – brain storm Oct 11 '14 at 20:26
  • 1
    @brainstorm - precisely. In any DI container (JavaEE/Spring/Guice), proxies are omnipresent. The proxying mechanism for EJBs however, is different from that of JSF managed beans – kolossus Oct 11 '14 at 20:37