On Wed, 2012-02-29 at 15:44 +0000, Gordon Sim wrote: > On 02/29/2012 03:21 PM, Kim van der Riet wrote: > > The current async store's use of DataTokens corresponds with the second > > proposal, ie one DataToken corresponds to a single enqueue. Switching to > > a MessageToken will require (at least from the current async store > > point-of-view) the maintenance of a map of queues on which this message > > is stored and then hang its enqueue-specific data there... This > > represents a departure from the current mechanism and an increase in > > complexity to the store. > > To be clear I am not suggesting that the same MessageToken is used for > enqueues on multiple different queues. > > In any case though, you must already be maintaining that map since the > current store interface only has a PersistableMessage with its > persistence ID as the context to an enqueue (and dequeue) along with the > PersistableQueue. Or am I misunderstanding? > Actually, the truth is worse... the current store discards its DataToken object when the enqueue is complete, then creates a new one and sets it up to look like an enqueued message when the dequeue occurs. This is because the current MessageStore interface provides no mechanism for the store to logically hook its metadata to a message. (This approach was initially simpler, and thought to be a better choice for performance than enduring the overhead of a map, though it has never been tested.)
You are correct though, in that if this facility _did_ exist, the store would have to maintain its own per-message map. I am uncertain if using an EnqueueToken at interface level would allow this to be skipped altogether, or if the requirement would simply shift to the broker. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
