Re: [Springframework-developer] message driven POJOs, a lightweight JCA container available

[<jas...@ma...>]

On 28 Oct 2004, at 09:52, j=FCrgen h=F6ller [werk3AT] wrote:
> James,
>
> Regarding pooling of the MessageListener objects: In many cases, this=20=

> won't be necessary, as the MessageListener implementation will be=20
> thread-safe anyway - similar to the DAO and service object case, where=20=

> a shared singleton instance is fine in 99% of the cases, so there's no=20=

> need to pool them (like Stateless Session Beans force you to).
>
> This means that in many cases, there's no need for a pool of=20
> listeners, i.e. there's no need to specify a TargetSource as message=20=

> handler - a plain target object will do, specified as shared=20
> MessageListener bean.

Agreed. I guess it depends if the MessageListener is stateful /=20
thread-safe or not.  Most of the MessageListener instances I write are=20=

not thread safe but that could be just me; though I can imagine ones=20
that are thread safe.


> If there's an actual need to pool those target listeners, this could=20=

> always be achieved through a ProxyFactoryBean with a pooling=20
> TargetSource, with the proxy implementing the MessageListener=20
> interface: =46rom the point of view of the ActiveMQ message =
dispatcher,=20
> it would simply keep calling the shared MessageListener onMessage=20
> method, but this time on the proxy which will delegate to one of the=20=

> instances in its backend pool.

Great idea.

> Essentially, it seems to me that the ActiveMQ container does not have=20=

> to be aware of Spring's TargetSource mechanism: Just invoking a=20
> provided MessageListener reference should be enough, without worrying=20=

> about the backend.
>
> Of course, the above argument does not affect the pooling of JMS=20
> Sessions in the background: That's the core of what ActiveMQ does=20
> here. I'm just talking about the need to pool the MessageListener=20
> implementation beans, which is probably as rare as the need to pool=20
> DAOs.

I guess it'd make things simpler if we assumed no pooling was needed=20
and then used the ProxyBeanFactory to add pooling when we need it.=20
Though the JCA ResourceAdapter already has to pool Endpoint objects=20
anyways in case they are stateful, so I figured it was easier to just=20
let the Endpoint talk to Spring's pool - but you're right, it'd be=20
cleaner to use the ProxyBeanFactory to add pooling when its required.=20
If nothing else it'd make it easier to use thread safe listeners=20
easier.

James
-------
http://radio.weblogs.com/0112098/