Hi Ishara, This very good. Yes, what we need is to make location transactions work, and then support / demonstrate how to use that with other JTA transaction via XA resources. Lets go though the code and decide on the plan. I already sent an invite.
--Srinath On Wed, Jul 17, 2013 at 11:34 PM, Ishara Premadasa <[email protected]> wrote: > Hi all, > > I have read on #1, #2 and #3 types of Transaction mechanisms as well as > have gone through the existing transaction source code in MB (Andes > broker). > > Regarding the three levels of transactions, AMQP supports three kinds of > transactions [1] [2] as, > > > - Automatic transactions: Every published message and acknowledgement > is processed as a standalone transaction. > > > - Server local transactions: Server will buffer published messages and > acknowledgements and commit them on demand from the client. > > > - Distributed transactions: Server will synchronise its transactions > with an external transaction coordinator, A TransactionManager which > coordinates one of more Resources. > > > IMO we have already partially implemented AMQP Transactions in MB but > however it is not a full implementation as only transaction commit() and > rollback() operations properly handled for Consuming, and not implemented > for Publishing scenario. The following is an overview of present AMQP > transactions implementation of MB 2.1.0 > > *(Interface) ServerTransaction > --------------> LocalTransaction > > --------------> AutoCommitTransaction : Implementation is > there but it is not used in broker level, as it is not intended to use > autocommit.* > > *Local transactions* > > Local transactions are applied to message Publish, Acknowledge and > Rejection scenarios. In the consuming side, the acknowledgements are made > transactional, with appropriate Commit/Rollback operations. > > When committing a message in Publish mode, basically the transaction > should be completed after the broker gets messages from client application > and successfully writing them into Cassandra storage. Similarly when > consuming messages, the transaction should be committed after the message > is received by client and the Message entry is correctly removed from the > Cassandra storage. When rollbacking the transaction, message needs to be > marked as 'Redelivered' and requeue back. > > The current code address the Basic.ack and Basic.reject scenarios when > consuming messages in a transacted session [3]. To perform adding/removing > from storage, a CassandraTransation instance is used here. > > *Basic Consumer : Commit()* > > { > startTxn(); > receiveMessage(); > dequeMessage ( > new Cassandratrnasaction(){ > deleteMesageEntryFromStorage(); > } ); > ackMessage(); > endTxn(); > } > > *Basic Consumer : Rollback()* > > { > startTxn(); > getUnAckMessage(); > setRedelivered(); > decrementUnAckMsgCount(); > requeueMessage(); or rejectmessage(); > endTxn(); > } > > According to my observation, currently AMQP transactions are not > implemented in Basic.publish mode and therefore we first need to decide on > a common implementation approach to address transaction requirements > described above across both Publish/Acknowledge mechanisms. After that it > is needed to handle JMS Local transactions in the Andes client level. > > However AMQP only guarantees atomicity when all transactions involve a > single queue. When there are multiple queues involved, there can be > incidents that, at a broker failure during commit() the effects of the > transaction can only be occurred in some of the queues [4]. To address this > scenario, we need to support distributed transactions. The Java Transaction > API (JTA) [5] provides standard Java interfaces between a > TransactionManager and the Resources involved in distributed transactions > as above. > > As our initial requirement is completion of Local transactions properly > for WSO2 MB, at the moment there is no need to using JTA in the > implementation. In addition both AMQP and JMS supports distributed > transactions with using X-Open XA architecture [6], where this can be used > when we need to support distributed transactions. > > Please fell free to add your concerns. > > Thanks! > Ishara > > [1]. http://www.amqp.org/specification/0-10/amqp-org-download > [2]. > http://rabbitmq.1065348.n5.nabble.com/Transactions-in-AMQP-td4803.htm<http://rabbitmq.1065348.n5.nabble.com/Transactions-in-AMQP-td4803.html> > l > [3].http://abeykoon.blogspot.com/2013/04/get-jms-local-transactions-to-work-with_21.html > [4]. http://www.rabbitmq.com/amqp-0-9-1-reference.html#class.tx > [5]. http://www.oracle.com/technetwork/java/javaee/jta/index.html > [6]. > http://en.wikipedia.org/wiki/Java_Transaction_API#JTA_implementation_of_the_X.2FOpen_XA_architecture > > > > On Mon, Jul 15, 2013 at 4:40 PM, Samisa Abeysinghe <[email protected]>wrote: > >> OK, got it. Thanks for the clarification. >> >> >> On Mon, Jul 15, 2013 at 9:13 AM, Srinath Perera <[email protected]> wrote: >> >>> Hi Samisa, >>> >>> AMQP transactions is a subset of JMS transactions we thought that as the >>> starting point. >>> >>> --Srinath >>> >>> >>> On Mon, Jul 15, 2013 at 8:09 AM, Samisa Abeysinghe <[email protected]>wrote: >>> >>>> I was under the impression that JMS transactions are of high priority, >>>> given the industry usage. Why have we picked AMQP over JMS transactions? >>>> Does AMQP get used more than JMS in transactional situations? >>>> >>>> >>>> On Fri, Jul 12, 2013 at 3:02 PM, Srinath Perera <[email protected]>wrote: >>>> >>>>> Ishara and myself chatted about this. >>>>> >>>>> There are 3 levels. >>>>> >>>>> 1. AMQP transactions >>>>> 2. JMS transactions >>>>> 3. JTA transactions >>>>> >>>>> Our first goal is to make AMQP transactions work. >>>>> >>>>> Ishara is working understanding differences of #1, #2, and #3 and >>>>> understanding how #1 should integrating with current MB. >>>>> >>>>> -- >>>>> ============================ >>>>> Srinath Perera, Ph.D. >>>>> Director, Research, WSO2 Inc. >>>>> Visiting Faculty, University of Moratuwa >>>>> Member, Apache Software Foundation >>>>> Research Scientist, Lanka Software Foundation >>>>> Blog: http://srinathsview.blogspot.com/ >>>>> Photos: http://www.flickr.com/photos/hemapani/ >>>>> Phone: 0772360902 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Samisa... >>>> >>>> Samisa Abeysinghe >>>> VP Engineering >>>> WSO2 Inc. >>>> http://wso2.com >>>> http://wso2.org >>>> >>> >>> >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> Director, Research, WSO2 Inc. >>> Visiting Faculty, University of Moratuwa >>> Member, Apache Software Foundation >>> Research Scientist, Lanka Software Foundation >>> Blog: http://srinathsview.blogspot.com/ >>> Photos: http://www.flickr.com/photos/hemapani/ >>> Phone: 0772360902 >>> >> >> >> >> -- >> >> Thanks, >> Samisa... >> >> Samisa Abeysinghe >> VP Engineering >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> > > > > -- > Ishara Premasada > Software Engineer, > WSO2 Inc. http://wso2.com/ > *Blog : http://isharapremadasa.blogspot.com/ > Twitter : https://twitter.com/ishadil > Mobile : +94 714445832* > > > -- ============================ Srinath Perera, Ph.D. Director, Research, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
