Re: Rr: [Springframework-developer] Why is TransactionProxyFactoryBean forced to be singleton

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

I'm not 100% sure I agree. At a minimum, we need to document this as an=20
alternative to TransactionProxyFactoryBean, since I think a lot of=20
people just using examples won't realize they can do it. But even then,=20
it's a fair bit more verbose than TransactionProxyFactoryBean, which is=20
also a lot more verbose than using BeanNameAutoProxyCreator on a bunch=20
of beans with the same basic handling.

One addition which would cover some cases is enhancing=20
BeanNameAutoProxyCreator, or creating some variant of it, so that it can=20
work in a prototype fashion. So when working in prototype mode, what it=20
produces and stuffs back in the context is a prototype=20
(isSingleton=3Dfalse) ProxyFactoryBean instance, effectively the same as=20
if the user had used the basic ProxyFactoryBean to do transactional=20
interception, in non-singleton fashion.

What do you think?

Regards,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>Wrapping prototypes with transactional proxies should work nicely when u=
sing ProxyFactoryBean plus TransactionInterceptor. The target there is ju=
st a bean name, not a bean reference - so this will work with a prototype=
, despite the FactoryBean being a singleton.
>
>TransactionProxyFactoryBean is essentially a convenience class that's re=
ally meant to be used for the typical case of singleton targets, referrin=
g to them via a bean reference. I'd prefer to leave it that way, recommen=
ding ProxyFactoryBean plus TransactionInterceptor for prototypes.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Friday, April 30, 2004 2:20 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Why is
>TransactionProxyFactoryBean forced to be singleton
>
>
>The nasty thing is that while it is relatively easy to make=20
>TransactionProxyFactoryBean non-singleton in the sense that it respects=20
>its internal 'singleton' property and generates a new proxy on each=20
>getObject() call if non-singleton, this is effectively useless since it=20
>will be operating on the same target, and the container will only give=20
>it the target once since all FactoryBeans are singletons unless the=20
>container gives it a new target each time, which currently there is no=20
>way to make happen since currently factorybean objects themselves have=20
>to be singleton in terms of the container and are only populated once.=20
>For this to work, the factorybean has to be a prototype, and the target=20
>has to be a prototype.
>
>While wrapping stateful objects like this is not as common as wrapping=20
>stateless objects, it's something we should be able to support.
>
>Can anybody see a simple way to do this, before we start mucking around=20
>with basic container behaviour (i.e. forced singleton status of=20
>factorybeans).?
>
>Regards,
>Colin
>
>
>Colin Sampaleanu wrote:
>
> =20
>
>>I just realized that TransactionProxyFactoryBean always returns true=20
>>for ProxyFactoryBean's the isSingleton() method, and internally does=20
>>not support non-singleton operation, since it only sets up the proxy=20
>>once in afterPropertiesSet().
>>
>>I have a case where a client of the beanfactory is using=20
>>bf.getBean("xxx"), and needs to get back a new transactionally wrapped=20
>>instance on every call, sine the object is stateful, unlike every=20
>>other service I've wrapped transactionally so far.
>>
>>Does anybody know why the class was set up to operate in singleton=20
>>mode only? It makes sense as a default of course, but I can't see=20
>>anything in the code precluding allowing it to operate in=20
>>non-singleton mode as well, if things were moved around a bit...
>>   =20
>>