EJB intance pool & Spring bean scoping

[burki]

Hi,

We're using EJB3 SLSB beans as remote delegates for Spring business service Pojo's. We're building a SOA backend service provider, so therefore we don't have any stateful service. For each Spring service bean there is an another EJB3 SLSB implementing same business interface. So relation is one-to-one. But from the instance point of view, situtation is different. EJB container keeps an instance pool for ejb beans, whereas Spring's default behaviour is using singleton. That means, we'll have more than one ejb instance referencing the same spring service singleton instance.

What i'm trying to figure out is, does it make sense to change spring bean scoping to "prototype" to be able to reference separate spring bean instance from each ejb instance? Is there any architectural concern / benefit of this approach? Since all services will be stateless, multi-threading issue should't be a problem. right?

Thanks for any help,

[kariem]

Burki,

What i'm trying to figure out is, does it make sense to change spring bean scoping to "prototype" to be able to reference separate spring bean instance from each ejb instance? Is there any architectural concern / benefit of this approach? Since all services will be stateless, multi-threading issue should not be a problem. right?

On the multi-threading level I would not see any problems, but that depends on how the services are implemented. In general, I am not sure how you could benefit from this approach, but perhaps you could explain a bit more?

In the EJB scenario, the developer usually wants the EJB container to produce isolated beans for each requires. By using the approach of an EJB injection interceptor, you could wire the required beans upon initialization of your SLSBs.

That way, instead of having a one-to-one relation between EJB and Spring beans, you could have a many-to-one relation with a pool of separate SLSBs for one underlying Spring bean.

Compared to the prototype solution, where Spring is responsible for the creation of separate instances, you would hand this over to the EJB container. On the EJB side you have the benefit of pooling, while Spring would always (I would not know a way to configure a different behavior) create a new instance based on the template from the bean context.

I would recommend leveraging the EJB system, if you don't already do that, because I don't see any benefit from instantiating prototype-based beans via the Spring context.

Hope this could help with your decision,
Kariem