On Wed, 2012-02-29 at 14:33 +0000, Gordon Sim wrote: > > Here are the options on this point: > > > > 1. Only message context: > > > > virtual void submitEnqueue(MessageHandle*, DataSource*, QueueHandle*, > > TxnHandle*, ...) = 0; > > virtual void submitDequeue(MessageHandle*, QueueHandle*, TxnHandle*, ...) = > > 0; > > I prefer 1 above. > > > 2. Message and Enqueue context: > > > > virtual void submitEnqueue(EnqueueHandle*, MessageHandle*, DataSource*, > > QueueHandle*, TxnHandle*, ...) = 0; > > virtual void submitDequeue(EnqueueHandle*, TxnHandle*, ...) = 0; > > In this case creating the EnqueueHandle would require the QueueHandle > in > question. I find this option more complicated and without a more > compelling case for it I would rather not pick that route. >
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. That being said, the current design should not be used as a template for a new interface unless it can be justified. I could go either way. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
