[rabbitmq-discuss] Transaction

Mon Jun 11 14:32:15 BST 2012

Hi Matthias,

I agree that the solution is to control the duplication of messages. The
worst case is that I say when messages are notifications to users when an
error has occurred while processing the message queue. The user receive
several messages in the same error. It would be nice in future have
transactions between queues. Something that implement the database systems
quite well. We would greatly facilitate the work.

Thank you very much for the answer

Matthias Radestock-3 wrote:
> 
> David,
> 
> On 06/06/12 10:32, David sUAREZ wrote:
>> I have the following problem. In my application I have the following
>> message
>> flow.
>>
>> 1) A publisher sends a message to a queue "A".
>> 2) A subcriptor receives the message from queue "A" and send this message
>> to
>> the process "P".
>> 3) In the process "P" I send a message to the queue "B".
>> 4) The subcriptor which received the message sends the ACK to RabbitMQ.
>>
>> The subcriptor uses a channel "C1" to process messages in the point 2.
>> And
>> the point 3 is sent the message to the queue "B" through another channel
>> "C2".
>>
>> I would like the ACK sent by the channel "C1" belonged the same
>> transaction
>> that the publication of the message by the channel "C2", that is showed
>> in
>> the point 3. Is it possible?. I have only seen  transactions in the same
>> channel. Not by connection.
>>
>> Why do I want this?. May be that I send the publication showed in section
>> 3
>> and the machine crash. Then the ack of subcriptor will not be sent. Then
>> the
>> "P" process re-processing the previous message and re-send the same
>> message
>> showed in the point 3. Duplicating messages.
>>
>> http://old.nabble.com/file/p33968899/rabbitmq.png
> 
> AMQP transactions are channel-bound, so what you want above is not 
> possible. Furthermore, AMQP transactions are only guaranteed to be 
> atomic when they involve a single queue. See 
> http://www.rabbitmq.com/semantics.html#tx for more details.
> 
> Generally you'll want to design your system s.t. it can cope with 
> duplicate messages. There are many more failure scenarios than the one 
> described above, and re-sending of messages, with the resulting 
> possibility of duplication, is usually the easiest way to handle them. 
> E.g. consider what happens in case of failures in steps 1 or 3; the 
> sender has no way of knowing whether the message made it through and 
> hence would have to re-send it.
> 
> Matthias.
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> 
> 
-- 
View this message in context: http://old.nabble.com/Transaction-tp33968899p33993156.html
Sent from the RabbitMQ mailing list archive at Nabble.com.