My MOM exists to keep me and my brothers from fighting: she takes notes one to the other, maybe 'forgets' the particularly nasty ones, makes sure there's a cooling off period, etc. The purpose of MOM is to decouple - propagating transactions with the message is a bad idea because you're using a hammer to turn a screw.
An asynch. invocation on the other hand, ought to take the transaction with it, but I think you want a different programming model than the JMS overhead crap (look up three object in JNDI, call three factories, sacrifies three virgin goats...) I wouldn't care if it were implemented on the same infrastructure as JBossMQ, but I'd really want a more light-weight programming model - like an asynchronous Aspect for the target object, or something...
-danch
marc fleury wrote:
one of my favorite topics is coming up again One day I will sit down and write a tx spec.
Ok frankly WHY DO WE CARE THAT MESSAGING IS ASYNCHRONOUS WITH RESPECT TO
TRANSACTION. Yeah I know the answer you could have a long running
transaction and messages and queues and bla bla bla. BS BS BS.
So the method returns immediately. SO WHAT? the listener that will pick
up the message and act upon it may very well want to synchronize with
the GLOBAL transaction going on in the web. And commit or rollback
according to the outcome.
The scenario is simple.
Image A does something and sends messages to n instances with a global
transaction associated to it.
n recievers get the message get the TPC and register with the global tx.
If the global tx is still running then all good 2phi dance starts bla
bla bla. if the tx is out (too old) then the guy who woke up late just
says "sorry can't register" and possibly no one cares or he can notify
(whatever the app rollback semantics are).
AT A SYSTEM LEVEL I DON"T SEE A REASON FOR THIS "BAD IDEA" SYNDROME. IN
fact it always has struck me that there is NO WAY to propagate a TX with
a message.
you know what? this is something we can VERY easily do in JBoss. Adding
the message in the new rewrite may be the usual 'put an interceptor
here' deal, once we make progress on the rewrite.
But the point is simple, the asynchronous nature of the transport
protocol should not have an impact on the definition of a web
transaction.
IN fact it is a requisite for web services (generic way)Tx definitions.
Many threads TX!
</water-walking>
marcf
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of danch
Sent: Wednesday, January 15, 2003 6:18 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Transaction propagation change
And having a way to do that would probably be a Bad Idea. Propogating a transaction through asynchronous transports doesn't sound like a good idea to me, anyway.
-danch
Hiram Chirino wrote:
Just a small correction.. your example would have to be inat least 2
units of work. There is NO WAY to put a JMS message andget it again
important forin a single transaction. Regards, HiramHaving a distributed transaction context is especially
a messageexample when you have a EJB from one jboss instance posting
to a JMS queue
on another jboss instance that in turn has a MDB that callsanother EJB onthat second instance. If I want that all to be under onetransaction andthus rollback as one business unit of work, there is no way to do
that (that
i'm aware of) with "native" JBoss in the 3.x series. Iknow one could useTyrex, but the author doesn't recommend using Tyrex in a production environment and so I'm a little leary to use it myself.
-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
