Sep 27th, 2010, 06:56 AM
@Transactional and <tx:annotation-driven> in several bundles
I'm in trouble using @Transactional and <tx:annotation-driven> in several OSGi bundles deployed together (using SpringSource DM Server).
Quick sum-up of my concerns:
After some experimentation I found that when two bundles are using annotations for transaction management, and if each bundle has its own transaction manager, entity manager and persistence unit, those bundles cannot be used together in the same framework.
It seems the problem comes from the @Transactional annotation, which seems to always use the transaction manager from the last deployed <tx:annotation-driven> tag, even from another bundle.
I found a lot of other threads stating that annotations cannot deal with multiple transaction managers, despite their transaction manager name argument.
So does anyone know how the annotation-driven transaction management works? Am I experimenting a bug? Did I misunderstand something?
And how an application context can possibly use a tag from another application context? Or again could I be completely wrong?
I'm using a SpringSource DM Server 2.0.0, and a Derby database.
A BasicDataSource object and an EclipseLinkJpaVendorAdapter object are exported by a bundle.
Those objects are used by two (unrelated) other bundles. Let's call them A and B. Each of them has its own persistence unit, and so its own entity manager and transaction manager.
A and B use annotations and load-time weaving for the transaction management (i.e <tx:annotation-driven mode="aspectj" />
and <context:load-time-weaver aspectj-weaving="on" /> are used in both module-context.xml).
Everything is fine as long as only bundle A is started.
Then if I start bundle B, the transactional calls from bundle A are not working anymore (no error, but nothing is persisted in the database).
Then if I uninstall bundle B and try to call again a method from A, I get a "BundleContext is no longer valid" error, and the trace shows that bundle A is trying to create the transaction manager bean from bundle B (whose bundle context is indeed no longer valid).
Everything said above works the same way if bundles A and B are swapped.
I tried to specify a name for the transaction manager in the "annotation-driven" tag and in all @Transactional annotations (with a different name in each bundle), but that didn't help.
So I stopped using annotations and use now AOP pointcuts instead with the <tx:advice> tag. And it's working. But that needs a lot of XML to add, almost the same in each transactional bundle (making it really not error-free after several copy-and-paste). Furthermore I don't manage to use load-time weaving with the AOP approach (but this should be the topic of another thread).
So I would be glad if someone could explain to me what is really going on there. Am I right to think that the problem comes from the annotations? Is there any other work-around better than using AOP directly?
Hoping someone will reach the end of this long post...
Oct 24th, 2010, 06:05 PM
Seems to be no activity on OSGi support anymore?!
Yes, as you figured out there are several issues having multiple bundles with transactional behavior. I am having the same problem as you already pointed out. Bundle A bootstraps the EMF and a JpaTransactionManager that refers to the EMF. The txManager is exported as OSGi service and imported from service bundles B, C. Read-only is possible but no insert-update-delete.
I noticed that SpringSource OSGi repository and this forum as well are not such active anymore. I stuck on JPA1.0 because the latest Hibernate 3.5 JPA2 is not available as OSGI, and so on ....
I really don't know which technology to use in future. For me dmServer was a quite good alternative to a JEE server, but without future.
For real modularized enterprise applications (a web app is only on part of that) I do not see what to use. No tcServer, no tomcat.
Dec 28th, 2010, 11:16 PM
@Transactional and <tx:annotation-driven> in several : works with spring 3.x?
Jan 3rd, 2011, 03:27 AM
No hanasakijiji, I had already tried this and it's not solving anything.
And about Spring 3.x, Springsource DM Server 2 already uses Spring Framework 3, so nothing new there.
Tags for this Thread