Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-04-30 13:41:54
|
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=20
TransactionProxyFactoryBean non-singleton in the sense that it respects=20
its internal 'singleton' property and generates a new proxy on each=20
getObject() call if non-singleton, this is effectively useless since it=20
will be operating on the same target, and the container will only give=20
it the target once since all FactoryBeans are singletons unless the=20
container gives it a new target each time, which currently there is no=20
way to make happen since currently factorybean objects themselves have=20
to be singleton in terms of the container and are only populated once.=20
For this to work, the factorybean has to be a prototype, and the target=20
has to be a prototype.
While wrapping stateful objects like this is not as common as wrapping=20
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=20
with basic container behaviour (i.e. forced singleton status of=20
factorybeans).?
Regards,
Colin
Colin Sampaleanu wrote:
> I just realized that TransactionProxyFactoryBean always returns true=20
> for ProxyFactoryBean's the isSingleton() method, and internally does=20
> not support non-singleton operation, since it only sets up the proxy=20
> 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 wrapped =
> instance on every call, sine the object is stateful, unlike every=20
> 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...
-------------------------------------------------------
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_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Dmitriy K. <dko...@ru...> - 2004-04-30 13:51:08
|
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
|
|
From: Colin S. <col...@ex...> - 2004-04-30 14:11:54
|
I'm not 100% sure I agree. At a minimum, we need to document this as an=20
alternative to TransactionProxyFactoryBean, since I think a lot of=20
people just using examples won't realize they can do it. But even then,=20
it's a fair bit more verbose than TransactionProxyFactoryBean, which is=20
also a lot more verbose than using BeanNameAutoProxyCreator on a bunch=20
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 can=20
work in a prototype fashion. So when working in prototype mode, what it=20
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 when u=
sing ProxyFactoryBean plus TransactionInterceptor. The target there is ju=
st 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 re=
ally meant to be used for the typical case of singleton targets, referrin=
g to them via a bean reference. I'd prefer to leave it that way, recommen=
ding 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=20
>TransactionProxyFactoryBean non-singleton in the sense that it respects=20
>its internal 'singleton' property and generates a new proxy on each=20
>getObject() call if non-singleton, this is effectively useless since it=20
>will be operating on the same target, and the container will only give=20
>it the target once since all FactoryBeans are singletons unless the=20
>container gives it a new target each time, which currently there is no=20
>way to make happen since currently factorybean objects themselves have=20
>to be singleton in terms of the container and are only populated once.=20
>For this to work, the factorybean has to be a prototype, and the target=20
>has to be a prototype.
>
>While wrapping stateful objects like this is not as common as wrapping=20
>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=20
>with basic container behaviour (i.e. forced singleton status of=20
>factorybeans).?
>
>Regards,
>Colin
>
>
>Colin Sampaleanu wrote:
>
> =20
>
>>I just realized that TransactionProxyFactoryBean always returns true=20
>>for ProxyFactoryBean's the isSingleton() method, and internally does=20
>>not support non-singleton operation, since it only sets up the proxy=20
>>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 wrapped=20
>>instance on every call, sine the object is stateful, unlike every=20
>>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
>>
|
|
From: Colin S. <col...@ex...> - 2004-04-30 15:02:43
|
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 a=
s=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=20
>> 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 Behal=
f
>> 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 prototyp=
e.
>>
>> While wrapping stateful objects like this is not as common as=20
>> wrapping stateless objects, it's something we should be able to suppor=
t.
>>
>> 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=20
>>> for ProxyFactoryBean's the isSingleton() method, and internally does=20
>>> not support non-singleton operation, since it only sets up the proxy=20
>>> 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
>>
|
|
From: Colin S. <col...@ex...> - 2004-04-30 15:21:02
|
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
>>>
>>>
>
>
|
