[rabbitmq-discuss] STOMP and transactions
alexis at rabbitmq.com
Fri Aug 20 18:59:02 BST 2010
What sorts of problems did you have getting RabbitMQ up and running,
that we could address?
2010/8/20 Göran Krampe <goran at krampe.se>:
> On 08/20/2010 06:55 PM, Tony Garnock-Jones wrote:
>> Hej Göran,
> Swedish! :)
>> I spotted your library over on squeak-dev - very cool. I'm pleased you're
>> trying it out against RabbitMQ.
> Hehe, yeah, I started with CoilMQ but I realized it doesn't even do
> receipts. I must say that getting Rabbit up and running was NOT trivial. You
> guys need to put out a Howto for that.
> But disregarding that, Rabbit seems nice. And yeah, I noticed your AMQP lib
> on SS, and funny enough searching for "STOMP" gives a hit on your private
> repo I think ;)
>> Transactions in AMQP (and STOMP, though STOMP's semantics are pretty
>> loose) are
>> not quite what you'd expect given what they mean in the DB world. They are
>> to *group* sets of messages ("SEND"s) together (atomically, more or less)
>> that either all or none are published. An additional wrinkle is the
>> of acknowledgements ("ACK"s) of messages delivered to the transacting
>> from the server: acknowledgements can be included in a transaction along
>> new publications.
>> This lets e.g. an RPC server receive a request, process it, and then
>> transactionally both acknowledge the request and send the reply message.
>> If the
>> transaction commits, the request is deleted from the server's queue, and
>> reply is enqueued for the RPC client; if the transaction aborts, the
>> remains enqueued waiting for another (or perhaps the same) RPC server
>> to pick it up and work on it, and the reply message is not sent.
> Right, this was my guess. But then I tried making a sunit test and... well,
> I start two sessions, let the first set up a subscription to 'wonderland',
> then let the second session do BEGIN and send two messages to 'wonderland',
> now, my naive understanding was that session one should not receive any
> message until session2 does COMMIT.
> But perhaps what is happening is that the messages are not *removed* from
> the queue until COMMIT? Hmmm. Ok. <scratching head> wonder how to rig a unit
> test for that.
>> With regard to hitting disk: persistence of messages is orthogonal to
>> transactionality in messaging systems like AMQP and STOMP.
> Right, kinda guessed.
>> I hope this helps. I read squeak-dev, too, so feel free to get in touch in
>> either place if you have further questions.
> regards, Göran
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss