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

[Dmitriy K. <dko...@ru...>]

I was writing to say the same thing, but Juergen's message came first ;-))

+1 for using ProxyFactoryBean + TxInterceptor for prototypes

Regards,
Dmitriy.


jürgen höller [werk3AT] wrote:

> Wrapping prototypes with transactional proxies should work nicely when using ProxyFactoryBean plus TransactionInterceptor. The target there is just 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 really meant to be used for the typical case of singleton targets, referring to them via a bean reference. I'd prefer to leave it that way, recommending 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 
> TransactionProxyFactoryBean non-singleton in the sense that it respects 
> its internal 'singleton' property and generates a new proxy on each 
> getObject() call if non-singleton, this is effectively useless since it 
> will be operating on the same target, and the container will only give 
> it the target once since all FactoryBeans are singletons unless the 
> container gives it a new target each time, which currently there is no 
> way to make happen since currently factorybean objects themselves have 
> to be singleton in terms of the container and are only populated once. 
> For this to work, the 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 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 around 
> with basic container behaviour (i.e. forced singleton status of 
> factorybeans).?
> 
> Regards,
> Colin
> 
> 
> Colin Sampaleanu wrote:
> 
> 
>>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 
>>bf.getBean("xxx"), and needs to get back a new transactionally wrapped 
>>instance on every call, sine the object is stateful, unlike every 
>>other service I've wrapped transactionally so far.
>>
>>Does anybody know why the class was set up to operate in singleton 
>>mode only? It makes sense as a default of course, but I can't see 
>>anything in the code precluding allowing it to operate in 
>>non-singleton mode as well, if things were moved around a bit...
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------
> 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. 
> http://ads.osdn.com/?ad_id149&alloc_id66&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer