> the only reason is that no one has previously written a 
> distributed tx 

it is not the ONLY reason, but yes it is the REAL one. 

marcf

> manager.  I wrote the  basic stuff we need in jboss 4, it should even 
> work with the trunk invoker.
> 
> david jencks
> >
> > If you have persistent JMS queues, then I would probably agree that
> > having a
> > distributed global transaction involved when asychronous 
> transports are
> > involved may not be best practice.  However, if a 
> non-persistent JMS 
> > queue
> > is used (and i don't know why anyone wouldn't use 
> persistence), then I 
> > can
> > see having a distributed transaction as very beneficial to the 
> > integrity of
> > a single unit of work.
> >
> > Dustin
> >
> >> -----Original Message-----
> >> From: marc fleury [mailto:[EMAIL PROTECTED]]
> >> Sent: Wednesday, January 15, 2003 6:37 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: RE: [JBoss-dev] Transaction propagation change
> >>
> >>
> >> 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 in
> >>> at least 2
> >>>> units of work.  There is NO WAY to put a JMS message and
> >>> get it again
> >>>> in a single transaction.
> >>>>
> >>>> Regards,
> >>>> Hiram
> >>>>
> >>>>
> >>>>> Having a distributed transaction context is especially
> >>> important for
> >>>>> example when you have a EJB from one jboss instance posting
> >>> a message
> >>>>> to a JMS queue
> >>>>> on another jboss instance that in turn has a MDB that calls
> >>> another EJB on
> >>>>> that second instance.  If I want that all to be under one
> >>> transaction and
> >>>>> thus 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.  I
> >>> know one could use
> >>>>> Tyrex, 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
> >
> 
> 
> 
> -------------------------------------------------------
> 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
> 



-------------------------------------------------------
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

Reply via email to