Stateless session bean keeping state???

[Wagner Danda Da Silva Filho]

Howdy Fellows...

I learned that a stateless session bean is not supposed to keep state between calls, right? So I did this quick test to verify that and I've found something weird...

Below is the code I used (a modification of EBJ3inAction chapter 1's example code)...

The Business Interface:

package ejb3inaction.example;
import javax.ejb.Remote;
 
@Remote 
interface HelloUser {                               
    void sayHelloSaveName(String name);
}

The Stateless Session Bean:

package ejb3inaction.example;
import javax.ejb.Stateless;
 
@Stateless
public class HelloUserBean implements HelloUser {                   
    private String savedName;
 
    public void sayHelloSaveName(String name) {
System.out.println("Hello [" + savedName + " / " + name + "]");
savedName = name;
    }
}

And here is the client code:

package ejb3inaction.example;
import javax.ejb.EJB;
 
public class HelloUserClient {
      @EJB
      private static HelloUser helloUser;
 
      public  static void main(String[] args) {
         helloUser.sayHelloSaveName( "John" + System.currentTimeMillis() );
         System.out.println("Invoked EJB successfully .. see server console for output");     
      }
}

When I run this multiple times (inside Glassfish's appclient) here is the output I get is Glassfish's log:

    
[#|2008-12-15T14:17:36.790-0500|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=76;_ThreadName=p: thread-pool-1; w: 35;|
Hello [null / John1229368656790]|#]
 
[#|2008-12-15T14:17:37.118-0500|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=76;_ThreadName=p: thread-pool-1; w: 35;|
Hello [John1229368656790 / John1229368657118]|#]
 
[#|2008-12-15T14:19:32.915-0500|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=77;_ThreadName=p: thread-pool-1; w: 31;|
Hello [John1229368657118 / John1229368772915]|#]

As you can see, the "savedName" variable is keeping the state although my bean is marked as @Stateless...

So, am I correct to assume that this is only happening because Glassfish is using a Object Pool (see the "thread-pool-1" string in the log)? Or is it really possible for a Stateless EJB keep it's state ?

I just want to make sure I correctly understand what a Stateless EJB can really do and what it can't do...

Thanks!
[ December 15, 2008: Message edited by: Wagner Danda ]

[Jimmy Clark]

Stateless Session EJB are not dedicated to one client. This means that many EJB objects can share only a few instances of a stateless bean. The bean does not maintain conversational state of a client it is servicing.
However, a stateless bean can have instance variables which maintain an internal state. It is important to remember that this state can never be visible to a client, as there is no guarantee that the same bean instance will service it every time.
[ December 15, 2008: Message edited by: James Clark ]

[Wagner Danda Da Silva Filho]

Hi James, thanks a lot for you answer.

You explained what I really wanted to know... That although a session bean is marked as @Stateless it can still keep a internal state (instance variables) but that we all know that it should not be used as it cannot guarantee the same instance will service every time. Great answer, thanks.

Now I got another question on top of this one. Let's say I do use instance variables in a Stateless EJB (for any weird reason ). Is there a way to force the container to "reset" this bean to it's original state (whatever you call it, send it to the GC, de-construct it, etc...) so that the next time a request for that same EJB service is made the instance variable will be clean/reseted?

Think of a scenario where you use that variable to store some secure information and you want to make sure it will be deleted/reseted when the EJB service is completed...

Thanks a lot (again)!

[Chaminda Amarasinghe]

Wagner Danda,

Your approach is not a good practice. Anyway If its really need, create a private method for reset in side the bean and call it after your business logic

[Jimmy Clark]

...so that the next time a request for that same EJB service is made the instance variable will be clean/reseted?

Client objects should not be "asking for" or "accessing" the internal variables of a Stateless Session EJB.

The business method implementations of the Stateless Session EJB should not expose it's internal state (if there is one) to client objects.

[Paul Anilprem]

Originally posted by Wagner Danda:
[QB
Think of a scenario where you use that variable to store some secure information and you want to make sure it will be deleted/reseted when the EJB service is completed...

Thanks a lot (again)![/QB]

That's exactly what local variables are for. Stateless session bean's service completes when its business service method ends. So you don't need any instance variable for storing stuff that you don't want to be there after the service completes.

[Wagner Danda Da Silva Filho]

Thanks Guys for all your answers. I just asked those "naive" questions to confirm my understanding. When preparing for Sun exams I like to explore all possibilities I can think of.

[Jaikiran Pai]

Originally posted by Wagner Danda:
I just asked those "naive" questions to confirm my understanding. When preparing for Sun exams I like to explore all possibilities I can think of.

And this forum is a good place to ask such questions. So feel free to ask more question, if any