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

[Rod J. <rod...@in...>]

ProxyFactoryBean supports stateful proxies. This is covered in the test
suite. As this is a minority usage I think it's reasonable that in the
interests of simplicity TransactionProxyFactoryBean, as a convenience,
focuses on the 98% usage.

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Friday, April 30, 2004 1:20 PM
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