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

[<jue...@we...>]

James,

Regarding pooling of the MessageListener objects: In many cases, this =
won't be necessary, as the MessageListener implementation will be =
thread-safe anyway - similar to the DAO and service object case, where a =
shared singleton instance is fine in 99% of the cases, so there's no =
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 listeners, =
i.e. there's no need to specify a TargetSource as message handler - a =
plain target object will do, specified as shared MessageListener bean.

If there's an actual need to pool those target listeners, this could =
always be achieved through a ProxyFactoryBean with a pooling =
TargetSource, with the proxy implementing the MessageListener interface: =
From the point of view of the ActiveMQ message dispatcher, it would =
simply keep calling the shared MessageListener onMessage method, but =
this time on the proxy which will delegate to one of the instances in =
its backend pool.

Essentially, it seems to me that the ActiveMQ container does not have to =
be aware of Spring's TargetSource mechanism: Just invoking a provided =
MessageListener reference should be enough, without worrying about the =
backend.

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

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of jas...@ma...
Sent: Thursday, October 28, 2004 10:24 AM
To: spr...@li...
Cc: de...@ac...
Subject: Re: [activemq-dev] Re: [Springframework-developer] Re:
[activemq-dev] Re: message driven POJOs, a lightweight JCA container
available


On 27 Oct 2004, at 20:11, Eugene Kuleshov wrote:
> James Strachan wrote:
>>> I think Eugene has a point.
>>>
>>> The work manager isn't the problem, it's integrating message=20
>>> delivery to mdbs without container support.  This is going to be=20
>>> even more unlikely to work for CMT mdbs.
>>>
>>> If you want to use your spring psuedo-mdbs inside a j2ee container,=20
>>> there's still the problem of transactional message delivery. =20
>>> There's no standard way to find the TM and even if you get it I=20
>>> would investigate extensively before thinking that using it directly =

>>> will give you the correct semantics.
>> Agreed - though we're delegating to Spring for this issue....
>
>   By the way, there was a huge discussion related to CMT and Spring=20
> manged transaction and as far as I remember everybody agreed that in=20
> general it is a bad idea to mix those.

BTW I think its worth saying, that in all the projects I've used JMS=20
(which is most of them over the last 5 years), I think I use XA=20
delivery less than 2% of the time. So for 98% of the time at least, I=20
tend to use regular JMS with no transactions and just use the regular=20
JMS acknowledge() or commit() mechanisms, which requires no J2EE=20
transaction manager or special container hooks whatsoever.

So even if the JCA Container never supported J2EE transactions or=20
didn't support them any where near as well as a full J2EE container,=20
its still very, very useful IMHO.

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



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer