EJBHomeFactory pattern and Stateless Session Bean

[ShengTa Tsai]

Although design pattern is not the objective of the SCBCD, i want to see if anyboby can give me an answer.
When i read about EJBHomeFactory pattern, i come up with a thought about Stateless SessionBean. According to EJB 2.0 spec(p66), the same EJBHome reference will create the same "stateless" SessionBean. The homeFactory cache the home object reference. If two clients concurrently request homefactory to get the home interface which is for stateless SessionBean, the two clients will get the same stateless session bean identity.(right ?)
Will this be a problem when multi-accession to the same stateless sessionBean?

[David Harrigan]

Hi There!
Good question, but you are assured by the container that no two clients will be executing in the same method of the same stateless session bean. So, having multiple clients access, say, 1 or 2 stateless session beans will cause no problems (apart from why a container is only creating 1 or 2 stateless session beans if a lot of clients are hitting it....but that's another story :-) )
-=david=-

[ShengTa Tsai]

Thanks for your information.
Base on your information, i think there will be only one client access the same stateless session bean even two clients get the same stateless session bean concurrently. Thank you .

[Magnus Stattin]

This is my view on this...
There will always be just one home bean and one EJBhome for a particular bean type, regardless of a factory is used or not. It will not be just 1 stateless bean instance created from that home. That would not make the application scale well at all. The spec states that all stateless beans from one home will have the same identity, that just means that they will all return true from an isIdentical call. There will be many different stateless bean instances but they will all have the same identity as far as the container is concerned.
/Best Regards Magnus

[Chris Lewold]

-) Stateless session beans are held in a pool.
-) It is up to the container when to create them. (E.g. initialize the pool at startup with 10 beans, or create them "on need" or whatever).
-) When a client invokes a business method on the ComponentInterface the bean is taken out of the pool, and associated with the clients EJBObject.
-) After using the business method the bean is de-associated from the EJBObject and put back into the pool.
Consequently there is no way one client can use the same bean as another client.
This is my view of things - hope it helps (and please correct me if I am mistaken)
Regards,
Chris Lewold

[Kathy Sierra]

I agree with the way Chris explained it.
The Container must guarantee that any one stateless bean will *not* be accessed concurrently. So you don't have to worry about thread safety with respect to any single bean. The bean will complete its business method for that client before it will get any other business method calls. But the very *next* call it gets, of course, can be from a *different* client.
cheers,
Kathy

[ShengTa Tsai]

Thank you all for responses.
The next question is even though container can promise that no two client will be use the same stateless session bean concurrently ,is it true that all clients that use the same home will be queued in order to wait for the same stateless session bean ?
Or all clients that use the same home interface would get different session beans in the container when isIdentical method always return true?

[Keith Rosenfield]

Hey ShengTa,

Originally posted by ShengTa Tsai:
Thank you all for responses.
It true that all clients that use the same home will be queued in order to wait for the same stateless session bean or all clients that use the same home interface would get different session beans in the container when isIdentical method always return true?

My understanding is that the container will always pull an available stateless session bean out the pool to service the client. If there are none available then I suppose it would do one of the following
- Create a new statless session bean to service the client.
- Block the client until one of the stateless beans becomes available.
I would get that it all depends on how the container is implemented.
The spec guarantees is that at any one time at most one client will be executing a business method of any particular stateless bean.
Hope this helps.
[ January 19, 2004: Message edited by: Keith Rosenfield ]