activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <>
Subject Re: Only memory transaction store with JDBC persistence adapter??
Date Tue, 29 Jul 2008 05:40:26 GMT

On 29 Jul 2008, at 05:41, bwtaylor wrote:

> 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
> 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:
> Sent from the ActiveMQ - User mailing list archive at

The journaled JDBC store uses a transaction log - can you not use that ?



View raw message