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

[<jue...@we...>]

If you use a PrototypeTargetSource with TransactionProxyFactoryBean, =
you'll get a new prototype *per method invocation* on the proxy. I =
assume what you actually want is a prototype proxy with a single =
prototype target, with all invocations on the proxy going to the same =
target object.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Friday, April 30, 2004 5:03 PM
To: spr...@li...
Subject: Re: Rr: [Springframework-developer] Why is
TransactionProxyFactoryBean forced to be singleton


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 prototype=20
target source creator that people can use, and even if there was, it's=20
somewhat of a pain for people to create one just for this purpose. Does=20
it make sense to have BeanNameAutoProxy creator by default register a=20
prototype custom target source creator? (it could still be overriden of=20
course). If you think about it, the current default BeanNameAutoProxy=20
creator default behaviour is wrong anyways in the face of wrapping=20
prototype beans, since it will generate a singleton proxy around just=20
one instance from the prototype bean that is being wrapped, instead of=20
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 =
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=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 that's =

>> really meant to be used for the typical case of singleton targets,=20
>> referring to them via a bean reference. I'd prefer to leave it that=20
>> way, recommending ProxyFactoryBean plus TransactionInterceptor for=20
>> 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=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 =
prototype.
>>
>> While wrapping stateful objects like this is not as common as=20
>> wrapping stateless objects, it's something we should be able to =
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 true =

>>> for ProxyFactoryBean's the isSingleton() method, and internally does =

>>> not support non-singleton operation, since it only 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
>>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. =

Take an Oracle 10g class now, and we'll give you the exam FREE.=20
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer