Re: [Springframework-developer] new bean factory and application context features

[Colin S. <col...@ex...>]

jürgen höller [werk3AT] wrote:

>Colin,
> 
>  
>
>>How do you see this being used (if at all) with the current
>>    
>>
>TransactionInterceptor, since its TransactionAttributeSource property
>gets satisfied via a MethodMapTransactionAttributeSource instance (which
>needs definitions in the format 'FQN.methodName'). While this works fine
>when doing individual interceptors for use with ProxyFactoryBean, short
>of adding new code I'm at a loss as to how I could use
>TransactionInterceptor with BeanNameAutoProxy to do transactions on all
>methods in all the beans I feed to the auto proxy.
>
>You need to use one shared TransactionInterceptor instance here, defining the attributes for the transactional methods of all the interfaces and classes involved:
><bean id="exampleTransactionInterceptor" class="org.springframework.transaction.interceptor.TransactionInterceptor">
>  <property name="transactionManager"><ref bean="myTransactionManager"/></property>
>  <property name="transactionAttributeSource">
>    <value>
>      example.ExampleBusinessInterface.exampleMethod=PROPAGATION_REQUIRED
>      example.ExampleBusinessInterface.anotherExampleMethod=PROPAGATION_REQUIRED
>      example.AnotherExampleBusinessInterface.exampleMethod=PROPAGATION_REQUIRED
>    </value>
>  </property>
></bean>
>
>That should work with multiple ProxyFactoryBeans that reference one single TransactionInterceptor, and thus also with BeanNameAutoProxyCreator.
> 
>  
>
Sure, that would work of course. I was thinking more along the lines of 
being able to handle at least the case of treating _everything_ with a 
set of specified transaction semantics (e.g. PROPOGATION_REQUIRED), 
without having to specify individual method matching regexes on each 
class. There is a use case (especially when you don't care about 
ultimate 'tuning' or when you want to defer that until later) for just 
turning on transactions for everything. This seems even more relevant 
when combine with BeanNameAutoProxy, so that you only have to add one 
simple bean ref in one place, and you have transactionional wrapping.

In my case for example, this would happilly cover the majority of my 
transaction handling needs, with some fine tuning here and there (using 
TransactionProxyFactoryBean) for maybe the 10-20% of the remaining cases...

Regards,
Colin