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

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

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...