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 <g...@redhat.com> wrote: > > > On 01/05/2016 11:42 AM, Robbie Gemmell wrote: > > > > > On 4 January 2016 at 19:59, Gordon Sim <g...@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-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
