[
https://issues.apache.org/jira/browse/QPID-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Simon updated QPID-503:
------------------------------
Attachment: dtx.gif
UML class diagram
> Dtx design notes
> ----------------
>
> Key: QPID-503
> URL: https://issues.apache.org/jira/browse/QPID-503
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Arnaud Simon
> Attachments: dtx.gif
>
>
> The following text provides information about the Qpid dtx support and can be
> added to the Qpid wiki:
> http://cwiki.apache.org/confluence/display/qpid/Qpid+Developer+Documentation
> (title) The AMQP Distributed Transaction Classes
> The distributed transaction classes provide support for the X-Open XA
> architecture. The dtx-demarcation class is used to demarcate transaction
> boundaries on a given channel that is subsequently used to perform AMQP
> native transactional work (produce publish messages). Transaction
> coordination and recovery operations are provided by the dtx-coordination
> class.
> A Transaction Manager uses RM Client XA interface to demarcate transaction
> boundaries and coordinate transaction outcomes. RM Clients use the
> dtx-demarcation class to associate transactional work with a transactional
> channel. The transactional channel is exposed to the application driving the
> transaction. The application can then use the transactional channel to
> transactionally produce and consume messages. RM clients use dtx-coordination
> to propagate transaction outcomes and recovery operations to the AMQP broker.
> A second coordination channel can be used for that purpose.
> More details about can be found at:
> - << link to >>
> https://wiki.108.redhat.com/wiki/index.php/AMQP:Transaction_SIG_dtx_XML
> - << link to >> dtx-classes-specification-document-v1.2.pdf (it is
> attached)
> - <<link to >> dtx-classes-presentation-v0.10-PMC-03142007.pdf (it is
> attached)
> (title) The Qpid Implementation
> As shown on the following class diagram, there are two protocol specific dtx
> classes, that is to say DtxDemarcation and DtxCoordination that are
> highlighted in yellow.
> << insert class diagram dtx.gif >>
> - DtxDemarcation
> DtxDemarcation interacts with the corresponding AMQChannel. The operation
> select creates the corresponding TransactionalContext (a channel has by
> default a non-transactional context). The operations start and end associate
> and disassociate a provided xid with the current TransactionalContext that
> percolates the call to the TransactionManager (operations begin and end
> respectively). Note that the operation end is responsible for acknowledging
> the messages against the context i.e. those messages are seen as being
> consumed under the currently associated xid.
> - DtxCoordination
> DtxCoordination directly interacts with the TransactionManager. Note that it
> is a requirement that the operation end is called on all involved channels
> (i.e. all the acknowledged messages have been specifically consumed under the
> provided xid).
> - TransactionalContext
> There are three flavours of TransactionalContext: the non transactional one,
> the local and distributed ones. The distributed and local contexts are very
> similar and both extend the abstract context. Note that the distributed
> context does not implement commit and rollback as this is DtxCoordination
> that is responsible for deciding of a transaction outcome.
> - TransactionManager and MessageStore
> Transaction manager and message store are linked as the message store may
> need to add transaction records to the transaction identified by a given xid.
> Moreover, the transaction manager may need to use the transactional
> facilities of the underlying store. This is the case of the JDBCStore and
> JDBCTransactionManager. The JDBCTransactionManager uses the transaction
> facilities of the JDBCStore for performing ACID operations during prepare and
> commit.
> This is the responsibility of the MessageStore to recover queues and
> exchanges and messages. Note that the JDBCTransactionManager delegates the
> responsibility of getting the list of in-doubt transactions to the JDBCStore
> but another implementation of TransactionManager may handle that directly.
> The MessageStore implementation should not load the messages in memory during
> recovery but only set the messageID. The message header, publish info and
> payload are lazily loaded. Note that the message payloads are currently
> loaded in memory. We can however easily implement a direct streaming of
> message payload on the wire (The MessageStore interface can be extended for
> supporting that).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
