marc fleury wrote:
No the crux of the problem is that JMS was designed to address the needs of providers of application integration infrastructure that's used for loosely coupled interfaces between systems. If you're loosely coupled enough to use JMS, you don't want the transaction propagated.The original point was that JMS allows you transact the message put. If the message put is part of the global unit of work and it has not committed, then no receiver can pick up the message (the put does not actually occur till we commit). This really has VERY little to do with the fact the jms is asynchronous.
Well I think the crux of the problem is that there is no propagation of
context with the JMS message.
Well, really it also ends at the start of 'synchronous' messages as well, if you're foolish enough to do put synchronous semantics over the top of JMS/MOM.
There is indeed a (weak) notion of transacting of sending and receiving
but essentially your transactional scope ends at the start of async
messages. Why ?
It's all because what we're talking about just doesn't make sense in a messaging integration type use case, where JMS/MOM makes sense. You're proposing something altogether different, more akin to a one-way from CORBA land. That's great, I love it, but referring back to how JMS does it is just confusing the issue.
-danch
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
