Announcement Announcement Module
No announcement yet.
Component based develop, multiple app contexts, sharing txns Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Component based develop, multiple app contexts, sharing txns

    I hope this hasn't already been addressed here. If so, flame me and point me to it, 'cause I can seem to find it.

    I am working on a larger project with multiple teams involved. For many reasons we have our work split up into smaller development projects. Some based upon convenience of teams and some due to the development of more reusable components. Both of these scenarios we will be using individual app contexts for each component and each logically separated project. We will also have a higher level app context for the entire app. This will contain all the common beans such as txn proxy templates, data sources, transaction manager, plus various other pieces of the app. My question relates more to the txn proxy template. Since each application context will need references to this bean, I need a common mechanism for refering to it. All of my transactional beans use the parent attr to wrap them within the current transaction. Since you can't use the property placeholder on the parent attr, that's not an option. So, my other choice is to enforce every component and project to use a common name for the txn proxy template as declared in the higher level application context that is shared.

    So, is there something I am missing? Or do I just need to mandate a common name be used for the txn proxy template bean id?

  • #2
    Randy, this is not really an answer to your question, but why not use org.springframework.transaction.interceptor.Transa ctionAttributeSourceAdvisor and org.springframework.metadata.commons.CommonsAttrib utes? That way your transaction requiring beans can just be added to the application context, and use their attributes to define their transaction requirements. Might work better on a large project. We use this approach on a large project, along with an Advisor for method security interception. Saves a lot of XML.


    • #3
      I'll look into


      Thanks, I will definitely look into these.


      • #4
        As an aside, whilst surfing tonight I found Spring and Acegi Security listed in Jakarta Commons Attributes' FAQ of users of the project!