|
From: Colin S. <col...@ex...> - 2003-10-15 13:41:11
|
The specialized TransactionAttributeSource approach would work fine.
This is obviously a trivial little class, but it would probably be worth
adding it to Spring itself (with the transaction attribute as a
parameter) so people could just create an instance as needed for this
type of usecase.
W/regards to redefining TransactionAttributeSourceEditor to allow for
wildcards also in the classname, that's a useful feature, but the
internal workings of the class would have to change. Right now, using a
MethodMapTransactionAttributeSource, essentially all the methods of the
specified classes get added to the transactional method map (if they
match the method regex). So this approach wouldn't work for regexes at
the class level. You'd probably have to do matches at runtime, with
consequently slower performance (although I guess you could cache the
hits and misses, to alleviate this, making the performance pretty well
identical on second and subsequent calls to the same method). What do
you think of this idea?
Regards,
Colin
jürgen höller [werk3AT] wrote:
>Colin,
>
>This is basically about a special TransactionAttributeSource implementation that would simply return the same TransactionAttribute for every method invocation. That should be easy enough to do:
>
>public class MyTransactionAttributeSource implements TransactionAttributeSource {
> public TransactionAttribute getTransactionAttribute(MethodInvocation invocation) {
> return new DefaultTransactionAttribute(TransactionDefinition.PROPAGATION_REQUIRED);
> }
>}
>
>Simply define it as a bean then, linking it to TransactionInterceptor's transactionAttributeSource property via a bean reference.
>
>As an alternative, we could refine the TransactionAttributeSourceEditor to allow for wildcards not only at the end of method names but already for the classname:
>
>not only "mypackage.MyClass.myMethod=PROPAGATION_REQUIRED"
>and "mypackage.MyClass.my*=PROPAGATION_REQUIRED"
>but also (at least) "*=PROPAGATION_REQUIRED"
>
>Juergen
>
>
> -----Ursprüngliche Nachricht-----
> Von: Colin Sampaleanu [mailto:col...@ex...]
> Gesendet: Mi 15.10.2003 03:31
> An: jürgen höller [werk3AT]
> Cc: spr...@li...
> Betreff: Re: [Springframework-developer] new bean factory and application context features
>
>
>
> 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
>
>
>
>
>
>
>
|