Skip to content

Supporting transactions #76

Open
fuson opened this Issue Jun 21, 2014 · 8 comments

4 participants

@fuson
fuson commented Jun 21, 2014

It's a very usefull feature for production processing :)

@squaremo
Owner

Oh, I thought everyone had given up on transactions in AMQP, since they have none of the properties that "transactions" are usually considered to have. What are you using them for?

@fuson
fuson commented Jun 21, 2014

We use it in case when we must have guarantee what if message finally dequeued then it processed, cause in case of server process crashe or restart we cant lost dequeued but not finally processed massages. Only transactions may helps. :(

@squaremo
Owner

Perhaps I have misunderstood, but acknowledgements would be adequate for that, wouldn't they?

  1. Dequeue message
  2. Process message
  3. Acknowledge message

If the server or the client crashes before 3., the message will get redelivered. Transactions don't make any difference.

@squaremo
Owner
squaremo commented Jul 6, 2014

It wouldn't be hard to add "transaction" channels to the client API. But I wouldn't want to encourage people to use them, since they don't do what the name suggests.

Did you figure out if you really need them?

@cookie-bytes

👎

@manchicken

I've seen transactions used quite well to manage dead-letter queues which have manual processing requirements. Either way, it's part of AMQP 0.9.1, should one really limit what's in the API just because they can't think of how they would use it, or should the implement as true to the spec as reasonable?

@squaremo
Owner

Either way, it's part of AMQP 0.9.1, should one really limit what's in the API just because they can't think of how they would use it,

I appreciate this point, and there's an element of that. I was more concerned that it would invite people to rely on transactions in RabbitMQ, which don't deserve the name, and thereby cause far more problems than it solves.

But I'm not dead set against them. With careful use they can make some failures a bit more recoverable.

@manchicken

I appreciate this point, and there's an element of that. I was more concerned that it would invite people to rely on transactions in RabbitMQ, which don't deserve the name, and thereby cause far more problems than it solves.

But I'm not dead set against them. With careful use they can make some failures a bit more recoverable.

As someone who maintains an AMQP library (Net::AMQP::RabbitMQ on CPAN), I appreciate your concern. There are some wrong ways to use the protocol, but I don't really think that the library should intentionally have gaps to prevent people from engaging in poor practices.

Transactions are in the spec because they have value, they're useful. I argue that we should have access to them in the library since they're in the spec, and that those who do silly things with the library are going to find ways to break things with or without the help of this library (you know this to be true).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.