qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aconway <acon...@redhat.com>
Subject Re: [C++/Java Broker] [Transactions]
Date Fri, 08 Jan 2016 23:38:14 GMT
On Wed, 2016-01-06 at 08:51 +0100, Olivier Mallassi wrote:
> Hi all,
> 
> 
> sorry.
> 
> I have tried to summarize all this content in this table
> https://docs.google.com/spreadsheets/d/1JilNwbBSftHxPZymJoaSeSA1uxpp9
> ZwXZyzDM9q6LQA/edit?usp=sharing
> 
> Hope that helps
> 
> oliv/
> 
> PS: thx for the precisions on the link between on
> session/transaction/process.

As Gordon pointed out my initial comments about dispatch and
transactions were over-simplistic. 

Dispatch does "link routing" and "message routing"

To support all AMQP 1.0 transaction styles we need to extend "link
routing" to "session routing" so a client can collect together all the
links in a transaction (including the AMQP transaction factory link)
and ensure they are all routed to the same domain (broker). Then
supporting TX or DTX is simple, we just need to forward the transaction
ID info.

Dispatch "message routing" deliberately decouples things so that even
on a single link, messages may be routed to/from many independent
brokers or non-broker endpoints. Simply forwarding AMQP transaction
information doesn't make sense there.

HOWEVER for DTX there might be another option. Dispatch could use AMQP
only to get the XA transaction ID from the local client. We could
forward the XA info without any session context and use it in a new
session context at the remote end. This would let dispatch participate
in arbitrary XA transactions that are not scoped to any single AMQP
broker (even ones that include non AMQP resources.) The trick would be
where to get the XA transaction from in the first place.

It is Friday so this may all be madness.

> 
> 
> On Tue, Jan 5, 2016 at 12:54 PM, Gordon Sim <gsim@redhat.com> wrote:
> 
> > On 01/05/2016 11:42 AM, Robbie Gemmell wrote:
> > 
> > > On 4 January 2016 at 19:59, Gordon Sim <gsim@redhat.com> wrote:
> > > 
> > > > On 12/30/2015 06:37 PM, aconway wrote:
> > > > 
> > > > > I believe dispatch *could* support at least some of the AMQP
> > > > > 1.0 TX and
> > > > > DTX modes even with message routing, we just haven't gotten
> > > > > there yet.
> > > > > 
> > > > 
> > > > 
> > > > For local transactions, any transfer or disposition related to
> > > > the
> > > > transaction needs to be routed to the same process, over the
> > > > same
> > > > connection[1], as that to which the transaction controller link
> > > > is
> > > > routed.
> > > > 
> > > > [1] If the multi-ssns-per-txn capability is not supported by
> > > > the process
> > > > in
> > > > question, the same session would have to be used. If the
> > > > multi-txns-per-ssn
> > > > capability was not supported then you would need a unique
> > > > session for
> > > > every
> > > > distinct transaction.
> > > > 
> > > > 
> > > To clarify that last bit, I asume you mean every currently active
> > > transaction?
> > > 
> > 
> > Yes, once the transaction is completed the session would be free to
> > be
> > associated with another one.
> > 
> > 
> > 
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> > 
> > 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message