qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arnaud Simon (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Updated: (QPID-503) Dtx design notes
Date Wed, 30 May 2007 15:46:15 GMT

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


Mime
View raw message