What is the reason for you needing to know this?
It is down to the container to decide when it is going to create the bean.
Thanks for your reply.
I have an application that need to provent the client login before the server service is completely started up. Therefore, at the client side, we call the server bean B home interface create. At the server side, the B.ejbCreate() has some validation logic and throw exception in case of services are not started up.
Here is a sample of client code:
1: // JNDI look up for B home interface.
2: BLocal b = (BLocal)b.create();
If the server side is not ready, I would the line 2 throw exception and won't go to line 3. But from the exercise, the validation exception throws at line 3. Looks to me that, home interface create does not really create a B bean instance in the server instance pool, it is when the remote interface method is called, and the container find there is no B instance in the pool, and then create a new instance of bean B.
This observation is a little bit different from what I read in books, so I would like to find out how JBoss container actually implemented. Maybe there is an other better way to prevent client login before server is ready.
So, any more input?? Any info is appreciated.
When an instance is created is defined with your caching configuration. You must never depend on such things.
For SLSB, the instance is created with the first call, not when create is called on the home interface.
You could deploy a (m)bean that checks deployment and returns true or false when done (or not).
A better way is to deploy the login bean with dependencies to every other deployment, so you can be sure if you can lookup the login bean, the rest is up. Or use your own deployment order...
Thanks for your reply. It helps a lot.
But just wondering why Jboss chose to implement the container that way. Cause now the home interface create method is very misleading...
Besides, I don't see the value of not creating the bean instance when ejbcreate is called, most likely, right after calling home interface create method, another method is called on the remote interface. Delaying the creation of bean instance does not seem serve much. Well, just my personal opinion. Maybe there were reasons behind it.
Read the EJB spec (stateless session bean). This is a feature described there for optimization, since SLSB "... minimize the resources needed to support a large number of clients...".