activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bwtaylor <bryan_w_tay...@yahoo.com>
Subject Re: Only memory transaction store with JDBC persistence adapter??
Date Tue, 29 Jul 2008 04:41:18 GMT

I'm kind of baffled by this, as I thought you had to flush the prepare out to
a durable media, too. This is in fact, what
http://activemq.apache.org/how-do-transactions-work.html claims happens. I
don't see how XA transactions with the JDBCMessageStore is achieving the
proper level of durability during the prepare stage. Hopfully one of the
ActiveMQ developers can clear this up. 

It looks like JDBCPersistenceAdapter's createQueueMessageStore(destination)
method instantiates a new JDBCMessageStore called rc and then returns
transactionStore.proxy(rc). The proxy method produces a MessageStore
implementation by constructing an inner class based on a new
ProxyMessageStore(messageStore), overriding addMessage and removeMessage to
proxy through the original MemoryTransactionStore to the delegate
messageStore, which is the JDBCMessageStore. The proxying happens by adding
an AddMessageCommand or a RemoveMessageCommand inner class implementation to
the Tx object (which is itself a static inner class of
MessageTransactionStore). 

This Tx objects can be stored in either of two ConcurrentHashMaps called
inflightTransactions and preparedTransactions. Calling prepare() on
MemoryTransactionStore just shuffles the Tx from the former to the later and
does not do anything else. In particular, it appears that the underlying
JDBCMessageStore is not involved in the prepare step. 

During the commit, the XATransaction calls commit, which passes through to
the transactionStore. In our case, MemoryTransactionStore gets and removes
the Tx object from preparedTransactions (assuming two phase commit is on),
and tx.commit() is called. The tx object executes the commands it added
above, first iterating over all adds and then all removes. When these
included JDBCMessageStore's addMessage or removeMessage, a JDBCAdapter is
used to issue SQL to the database. The underlying jdbc connection commits
when told to do so from the TransactionContext object, which commits when
JDBCPersistenceAdapter's commitTransaction method is called. I don't quite
see how this is connected to the XATransaction's calling of commit().


-- 
View this message in context: http://www.nabble.com/Only-memory-transaction-store-with-JDBC-persistence-adapter---tp18657395p18705185.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message