1. multiple threads in one tx. This is doable technically and may produce determinate results if all threads access only different resource managers. If any access the same resource manager, you will easily get indeterminate results (e.g. one thread adds 2, the other thread mulitplies by 10, you start with 1, you can get 30 or 12 depending on order). This is not messaging in any sense I can think of.
2. transactional messaging. Basically the only idea here is "commit a message to a queue/topic and it is guaranteed to be eventually delivered". Trying to make the transaction go with the message doesn't make any sense to me. There is no point in using messaging if you do this. Just start lots of threads, as in (1).
Thinking about it more, I think you could get each "message branch" to prepare or rollback its work unilaterally when it finishes, but I think it would then have to inform the "master" tm of its vote. I don't see any way to eliminate the master tm having to send a final commit message to all the parties. I think this might eliminate one round trip call from "branch" to tm compared to (1) (the "i'm done with this method call" from branch to master and the "prepare" call from master to branch would be eliminated).
I'm not sure the "messaging" part of this adds anything. We could do the same thing with just threads much more easily. If you think doing an optimization specifically with messaging like this adds something useful please provide a concrete example.
Is this what you had in mind? Is it really worth doing?
thanks
david jencks
On Wednesday, January 15, 2003, at 06:37 PM, 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 changeAnd 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 2units of work. There is NO WAY to put a JMS message andget it againin a single transaction. Regards, HiramHaving a distributed transaction context is especiallyimportant forexample when you have a EJB from one jboss instance postinga messageto 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------------------------------------------------------- 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
-------------------------------------------------------
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
