Removing a Stateless Session Bean

[jorge_el_curioso]

Hi,

I am using Jboss 3.0.2, and I have two questions.

1.
Suppose you have a Stateless Session Bean and two threads sharing a reference to it. If while thread A is waiting for a remote method to finish, thread B calls remove() on the Bean, what would happen to thread A?

The answer I'm hoping for is that the method call on thread A will run its course and not fail with some (unexpected) exception.

2.
If you repeatedly call remove(), and the create() on a Home interface for a Stateless Session Bean, say once a minute, should I be concerned that garbage might accumulate on the server side?

Thanks!
Brian

[jamesstrachan]

Brian,

It doesn't quite work like that !

With Stateless Session Beans, the container maintains a pool of Stateless Session Beans in the container.

Each client instance that calls a method on the SSB is handed a reference to one of the idle SSB's in the pool. So there should never be two clients sharing a reference to the same SSB within the pool, and calling remove() from one client cannot affect any other client.

In addition, SSB's in the pool are not physically removed when the remove() method is called from the client. The remove() method may free resources on the client but has no effect on the server.

Use of a pool of SSB's is critical because it avoids the need to create SSB's on each method call - thus avoiding object thrashing and garbage collection.

You should also note that the ejbCreate() method on the SSB is called when an SSB is created as the pool is initialised or enlarged - not when you call create() on the client. Simiarly, the ejbRemove() method is only called by the container if the container decides to reduce the size of the pool by removing SSB's.

James

[jorge_el_curioso]

Thanks James.

I guess maybe I should explain a bigger picture. I have a singleton that may be accessed by multiple threads. There are functions in this object that use a stateless bean. Because this is a singleton, different threads would be sharing the same reference to the bean.

Now, is this scenario even a good idea? Or should I synchronize all accesses to the bean? Or maybe JBoss already does the synchronization?

A specific example: Let's say the bean reference is x. x is a variable shared by two threads. If you call x.doSomething() from one thread and at the same time call x.doSomethingElse() from another thread. What can we assume or not assume about what might happen?

Thanks!
Brian

[darranl]

You can NOT and WILL NOT have two clients using the same stateless session bean concurrently. Unless you have configured the pool differently there will be two stateless session bean instances one for each client.

If you call x.doSomething() from one thread and at the same time call x.doSomethingElse() from another thread you can assume that there will be two instances of the stateless session bean, one for each invocation.

[kalyan120]

Let's say I have a singleton as below:

public class Singleton
{
 private TradeProcessor myProcessor = null; // SSB
 private static Singleton INSTANCE = new Singleton();

 private Singleton()
 {
 //lookup something and then create as below
 myProcessor = home.create();
 }

 // singleton accessor method

 private void foo1()
 {
 myProcessor.bookTrace("1234","100","IBM","25"); //ID,#,SYM,RATE
 }

 private void foo2()
 {
 myProcessor.amendTrade("1234","50","IBM","25");
 }
}

and let's say I have two client methods calling these methods (in different threads) as:

Singleton.getInstance().foo1();

Singleton.getInstance().foo2();

In this case, Singleton object has only one instance of TradeProcessor (which is only associated with only one Proxy in JBoss client container). Where is the guarantee here that, the same SSB instance is not used by multiple clients?

Will the Proxy take care of directing the call to a different SSB instance for every client used by it?

Thanks,
Kalyan.

[jamesstrachan]

Kalyan,

I'm not quite sure where you are coming from.

The code sample that you include won't compile (attribute home is not defined).

The class is not a session bean (doesn't implement the SessionBean interface).

The class is not a singleton (doesn't have a private constructor and a getInstance() method as shown below :-

public class aSingleton {

 private aSingleton theSingleton = null;

 private aSingleton() {}

 public aSingleton getInstance() {

 if ( theSingleton == null) {
 theSingleton = new aSingleton();
 }

 return theSingleton;

 }

}

You need to recollect that a session bean does operations whilst singletons and entity beans represent objects or data.

We do try to be helpful in these forums, but I would respectfully suggest that you need to talk to some J2EE people in person to make sure that you have a full understanding of the technologies.

James

[kalyan120]

Thanks for your suggestions. I know that they won't compile. It's all pseudo code. I'm sure if you have would have understood the context, you wouldn't have tried to compile the class in your brain and you wouldn't have recited, what a session bean does and what an entity bean is.

Regards,
Kalyan.

[patelcr]

The answer to your question "Will the Proxy take care of directing the call to a different SSB instance for every client used by it?" is more or less YES. You have to remember that with stateless session beans, your handle to the Remote Interface is nothing more than a proxy to JBoss. Calls on the remote interface are marshalled to JBoss which then grabs any available instance of the associated SSB to handle your request. Only with StateFULL session beans is it valid to say that your handle to a Remote interface is tied to one instance of the EJB.