I would like to know if the Spring container has any impact on the transaction management if it is only used for component lookup.
I currently have a J2EE application, deployed on JBoss, where there are stateless session beans on top (session facades), and POJOs below. Hibernate, managed by JBoss, is used for handling persistency. All use cases start by a RMI client or a SOAP client connecting to one of the session facades. Transactions are managed by the JBoss container. The application is running on a JBoss cluster. I do not have a web application directly tied to the JBoss application.
I want to rewrite my application, so that all POJOs becomes Spring beans. I want to use ContextSingletonBeanFactoryLocator to enable the session beans to get hold of the POJOs directly underneath them. These POJOs will be wired to the rest of the POJOs using Spring configuration files.
There will be cases where a POJO, triggered by a use case starting at a session facade, will make a RMI call to another session facade bean, possibly running in a separate JVM (in other words, there will be transactions spanning across two or more clustered session beans.
Transaction mode for the session beans will mostly be "required".
Does it make a difference, when it comes to JBoss' container managed transactions, if I fetch all POJOs from a Spring container instead of creating them the "old" way?
Please do not ask me to convert to Spring managed transactions. I will not do that, and I will also not rewrite my session beans to be subclasses of Springs convenience classes for session beans. I do appreciate the benefit from using Spring more extensively, but in this particular case I simply cannot do that in a hurry.