Major Description
Summary:
The new TransactionLog interface takes a list of queues upon which to enqueue a new message.
This approach allows us to do away with reference counting for messages that are only on the one queue, but it does require that the all the queues the message should be enqueued upon are sent via a single enqueue.
The management console cannot know what queues the messages are on once delivery has completed so there will need to be additional synchronisation to correctly enqueue a live message on to a new queue.
One approach that will work for move would be to check if we have a list of enqueues for the message and whilst holding the lock for that list add the new queue to it.
For copy what we can simply use the normal enqueue logic an ensure that the new enqueue call includes the current queue and the new queue. That way if we don't already have a reference to this queue then it will gain one. If delivery is still proceeding here though then it is conceivable that the message is acked and deleted before the copy completes. This would be ok as you would get an error, the problem exists where we do the enqueue and the dequeue call has been made before our enqueue. If we only had the message on the one queue there would be no way to guarentee that the enqueue didn't cause the message to be left on the queue even though the client just acked the message.
Is that clear? I can add more details if required.