If you think of persistence in the same way you would a POP3 store, 
i.e the object of the persistence store is more to provide reliability in that 

1: Write incoming message to disk,
2: Maintain a journal of actions taken to the message
3: Remove the message from the store once consumed.

So the persistence would be invoked on every broker that participated in a 
message exchange
to ensure consistency across the brokers. There is no master storage nor is a 
message 'replicated' to all nodes.

/je
On Nov 15, 2010, at 7:36 AM, Steve Cohen wrote:

> I am in the phase of imagining what using ActiveMQ to design a wrapper around 
> a legacy process would look like, and reading the book, which I have bought.  
> I should say that I am impressed so far with ActiveMQ and the mapping of what 
> it does with what I am trying to do seems very good.
> 
> I am trying to understand the relation of persistence to the "network of 
> brokers" concept.  In a single standalone broker deployment, it's simple.  
> You either enable persistence of one flavor or another, or you don't.
> 
> But what does this look like in the "network of brokers" concept?  There is 
> something appealing in this model to my situation, of deploying a server-side 
> application in which each instance has an instance of the broker embedded 
> within it, but what are the consequences in terms of persistence?  Would 
> there just be one persistent store, with a suitable backup arrangement?
> 
> Please help me untangle the consequences of these two concepts, which are 
> starting to boggle my mind a bit.
> 

Reply via email to