StatefulBeans inside StatelessBeans

[Amirtharaj Chinnaraj]

Hi All,

We are using EJB stateless Bean to expose a Web-service. this Stateless Bean is having a Statefull Bean as instance variable. As of now the web-service is working fine and i don't have any issues, the reason why we have sate full bean is to Avoid creating proxy object used by the web-service more than once, And these proxy reside inside the statefull beans.

My Question is is that advisible to have a statefull Bean inside the stateless Bean. i have read in EJB3 in Action. that stateful bean should not be used inside stateless bean. However their is no justification why it not be used like this. So i request to share your thoughts and correct me if iam wrong.

thanks
Amir

[Roger Sterling]

Web Services by design are stateless. If state needs to be tracked, its up to the caller (client) to do so, not the callee (server). Your proposed design is not workable and not recommended.

To perform the action of maintaining a single sign on, pass a token back in he Web Service response which the caller will provide back to the Web Service on subsequent calls. Don't forget to expire the token periodically and use OAuth rather than Basic Auth.

[Rob Spoor]

I agree that stateless session beans should not contain stateful session beans. Instead, use the HttpSession to store the SFSB reference. That way your SLSB can retrieve the SFSB for the current request's session, and all users get their own SFSB.

[Amirtharaj Chinnaraj]

Thanks for the reply Rob,

The purpose of SFSB reference inside my SLSB is to hold a Proxy over which i will call my JAX-WS call. My intention is not to maintain any user state. My intention is to create the Proxy(using a WSDL)once during the application startup. And this keep the proxy inside a stateful session bean. to avoid creating a same proxy for each request again again.

please correct me if my approach is wrong. Also please help me to understand why stateFull session Bean should be Kept inside a stateless bean

[Rob Spoor]

Whenever your SLSB is initialized, it may create a new SFSB. You can't guarantee that the same SFSB instance will be used.

It seems like you want a singleton been, so instead of using @Stateless use @Singleton in combination with @Startup. However, singleton beans have drawbacks too - there is only one instance, so you'll have to configure the class if you need to allow concurrent access to the bean from multiple threads. By default only one method call can occur at a time (since the defaults are @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER) plus @Lock(LockType.WRITE)).