[ 
https://issues.apache.org/jira/browse/QPID-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arnaud Simon updated QPID-503:
------------------------------

    Attachment: dtx-classes-specification-document-v1.2.pdf

dtx specification doc

> 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-classes-presentation-v0.10-PMC-03142007.pdf, 
> dtx-classes-specification-document-v1.2.pdf, 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.

Reply via email to