Announcement Announcement Module
Collapse
No announcement yet.
best way to support multiple transaction managers with Roo Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • best way to support multiple transaction managers with Roo

    Hi,

    We are using Roo in a multi-module project that uses several databases. The web application has those modules as dependencies and loads all corresponding application contexts.

    To properly modularise the application, we have created separated JPA infrastructures per module -in each application context- and used @RooEntity(... persistenceUnit=X), which generates the right @PersistenceContext ITD annotation.

    However, Roo creates all the ActiveRecord methods with @Transactional but no value to qualify an specific transaction manager (see http://static.springsource.org/sprin...ttransactional).

    Because we hit issues, as a fix, we are, at the moment, annotating the public methods on the business beans (which in turn use Roo's JPA persistence methods and finders) with
    @Transactional("<TX manager name>"). Is this the best way?

    Or probably Roo should allow us to configure the @Transactional qualifier in @RooEntity...?

    Any thoughts?

    cheers, Carlos

  • #2
    I can add the tx manager name to @RooEntity - please riase a an improvement request

    As a matter of interest, I'm curious, for ROO-120, how are your modules defined and what are they called? For example, in the three jobs before joining SpringSource, typically I used modules such as a core, war and ear as a minimum. The war and ear artefacts could be deployed to Tomcat and/or WebSphere, depending on a Maven profile.
    Alan

    Comment


    • #3
      Thanks for your reply Alan. Improvement requested [https://jira.springsource.org/browse/ROO-2213]

      Our use of Roo is not standard. What we are doing can be summarized as:
      1. we use maven
      2. we create new modules by copying the skeleton of existing Roo modules, stripping all the source, resources, etc. Leaving just the aspectj weaver and Roo nature in the pom (more or less).
      3. we create the application context, unfortunatelly Roo doesn't allow (AFAIK) to have custom names for the App Context, so we use applicationContext.xml.
      4. we start the Roo shell and instruct Roo to give us persistence layer. It puts all the stuff in the App Context, creates persistence.xml etc.
      5. we can now use Roo annotations in our domain classes.
      6. We rename the app context and persistence. (From that on Roo gets lost)
      7. In our latest hack, we learned how to provide custom transaction manager, entity manager factory, etc. So we give them names like (module)TM, (module)EMF, (module)DS where (module) is the module we introduce. In RooEntity we use the persistence unit name we crafted. So, at runtime our domain classes get the proper EntityManager and it's all fine.
      8. Those modules are declared dependencies of the web app. And the web.xml gets all application contexts loaded using a wild card. Because we use different JPA-related beans in all modules, they co-exists without conflicts. [Some may call our approach to those modules, "embeded" as they get just included as jars]
      9. We also use JMS via Apache Camel, and all seems to be ok (i.e. our JPA work).

      I know this is too vague; hopefully once we finish we will be able to spend sometime to share our experience.

      Kind regards
      Carlos

      Comment


      • #4
        https://jira.springsource.org/browse/ROO-2213 has been completed. Please read the note on the ticket

        Comment

        Working...
        X