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

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

Ok, (on looking at the logs) I just realized that for prototype target=20
beans, BeanNameAutoProxyCreator is applied to the prototype after it's=20
created, so in fact BeanNameAutoProxyCreator is immediately usable with=20
prototypes. I had not know that BeanNameAutoProxyCreator was applied at=20
all to prototype beans.

So this works. My only concern is that it's not incrredibly efficient if=20
you have a bunch of these BeanPostProcessors registered on prototypes=20
like this, as compared to the alternative mentioned below. However, the=20
alternative mentioned below is not implementable anyways, since at=20
container startup there won't be any instance of the prototype bean for=20
the postprocessor to work with. You would really have to do this with a=20
BeanFactoryPostProcessor instead of a BeanPostProcessor.

Regards,
Colin


Colin Sampaleanu wrote:

> Actually, it looks like all that would be needed to do is set a=20
> prototype target source creator of some sort into the=20
> CustomTargetSourceCreators list. Now there is no non-abstract=20
> prototype target source creator that people can use, and even if there=20
> was, it's somewhat of a pain for people to create one just for this=20
> purpose. Does it make sense to have BeanNameAutoProxy creator by=20
> default register a prototype custom target source creator? (it could=20
> still be overriden of course). If you think about it, the current=20
> default BeanNameAutoProxy creator default behaviour is wrong anyways=20
> in the face of wrapping prototype beans, since it will generate a=20
> singleton proxy around just one instance from the prototype bean that=20
> is being wrapped, instead of ensuring a prototype is returned each time=
.
>
> Regards,
> Colin
>
> Colin Sampaleanu wrote:
>
>> I'm not 100% sure I agree. At a minimum, we need to document this as=20
>> an alternative to TransactionProxyFactoryBean, since I think a lot of=20
>> people just using examples won't realize they can do it. But even=20
>> then, it's a fair bit more verbose than TransactionProxyFactoryBean,=20
>> which is also a lot more verbose than using BeanNameAutoProxyCreator=20
>> on a bunch 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=20
>> can work in a prototype fashion. So when working in prototype mode,=20
>> what it produces and stuffs back in the context is a prototype=20
>> (isSingleton=3Dfalse) ProxyFactoryBean instance, effectively the same=20
>> as if the user had used the basic ProxyFactoryBean to do=20
>> transactional 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=20
>>> when using ProxyFactoryBean plus TransactionInterceptor. The target=20
>>> there is just a bean name, not a bean reference - so this will work=20
>>> with a prototype, despite the FactoryBean being a singleton.
>>>
>>> TransactionProxyFactoryBean is essentially a convenience class=20
>>> that's really meant to be used for the typical case of singleton=20
>>> targets, referring to them via a bean reference. I'd prefer to leave=20
>>> it that way, recommending ProxyFactoryBean plus=20
>>> TransactionInterceptor for prototypes.
>>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...]On Beha=
lf
>>> 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=20
>>> respects its internal 'singleton' property and generates a new proxy=20
>>> on each getObject() call if non-singleton, this is effectively=20
>>> useless since it will be operating on the same target, and the=20
>>> container will only give it the target once since all FactoryBeans=20
>>> are singletons unless the container gives it a new target each time,=20
>>> which currently there is no way to make happen since currently=20
>>> factorybean objects themselves have to be singleton in terms of the=20
>>> container and are only populated once. For this to work, the=20
>>> factorybean has to be a prototype, and the target has to be a=20
>>> prototype.
>>>
>>> While wrapping stateful objects like this is not as common as=20
>>> wrapping stateless objects, it's something we should be able to=20
>>> support.
>>>
>>> Can anybody see a simple way to do this, before we start mucking=20
>>> around with basic container behaviour (i.e. forced singleton status=20
>>> of factorybeans).?
>>>
>>> Regards,
>>> Colin
>>>
>>>
>>> Colin Sampaleanu wrote:
>>>
>>> =20
>>>
>>>> I just realized that TransactionProxyFactoryBean always returns=20
>>>> true for ProxyFactoryBean's the isSingleton() method, and=20
>>>> internally does not support non-singleton operation, since it only=20
>>>> sets up the proxy 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=20
>>>> wrapped instance on every call, sine the object is stateful, unlike=20
>>>> every 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
>>>
>>>
>
>