You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Aidan Skinner <ai...@gmail.com> on 2010/04/01 02:26:24 UTC
[java] transaction handling
I've recently been wrestling with transaction handling in the java
broker in the context of 0-9-1 compliance. We're currently not
strictly spec compliant with 0-9-1 as we will resend messages that
have been rolled back. 0-9 and 0-8 are... ambiguous... on this matter,
and I've been trying to retain current behaviour for them.
However, it's a) a massive PITA and b) probably Not What You Want. If
you're rolling back a consume it's almost certainly because you can't
cope with the message.
If you think b) I'd like to float the idea of 0.8 being the "we are
breaking backwards compatibility" release so we can fix the conf file,
the command line etc.
Thoughts?
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] transaction handling
Posted by Martin Ritchie <ri...@apache.org>.
On 21 May 2010 17:57, Gordon Sim <gs...@redhat.com> wrote:
> On 05/21/2010 02:43 PM, Martin Ritchie wrote:
>>
>> On 1 April 2010 01:26, Aidan Skinner<ai...@gmail.com> wrote:
>>>
>>> I've recently been wrestling with transaction handling in the java
>>> broker in the context of 0-9-1 compliance. We're currently not
>>> strictly spec compliant with 0-9-1 as we will resend messages that
>>> have been rolled back. 0-9 and 0-8 are... ambiguous... on this matter,
>>> and I've been trying to retain current behaviour for them.
>>>
>>> However, it's a) a massive PITA and b) probably Not What You Want. If
>>> you're rolling back a consume it's almost certainly because you can't
>>> cope with the message.
>>>
>>> If you think b) I'd like to float the idea of 0.8 being the "we are
>>> breaking backwards compatibility" release so we can fix the conf file,
>>> the command line etc.
>>>
>>> Thoughts?
>>
>> I don't read the spec in the same way.
>>
>> From the 0-9-1 Spec:
>> 1.9.2.5. Method tx.rollback (ID 30)
>> This method abandons all message publications and acknowledgments
>> performed in the current
>> transaction. A new transaction starts immediately after a rollback.
>> Note that unacked messages will not be
>> automatically redelivered by rollback; if that is required an explicit
>> recover call should be issued.
>>
>> I read that as the unacked messages will not be automatically given
>> back to the client. So we should put them back on the queue and let
>> the client fight it out with other cilents to see who gets them.
>
> My understanding is that they would remain in the 'acquired' state, not
> acked but not requeued. The client could then decide to call recover
> explicitly to either requeue them or have them redelivered (or it could
> simply replay them itself if held locally).
>
> In 0-8/0-9 it was not explicitly stated that there should be a
> recover(requeue=false) implied by rollback but we assumed this as the spec
> did prohibit an explicit recover call for transactional sessions. 0-9-1
> explicitly stated that the recover was not implied, but allowed the recover
> to be called on a transactional session if desired.
Thanks for the clarification.. Sounds like we should be calling a
recover on the 0-9-1 session then, and stop the Java broker
'auto-recovering' as it is just now.
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] transaction handling
Posted by Gordon Sim <gs...@redhat.com>.
On 05/21/2010 02:43 PM, Martin Ritchie wrote:
> On 1 April 2010 01:26, Aidan Skinner<ai...@gmail.com> wrote:
>> I've recently been wrestling with transaction handling in the java
>> broker in the context of 0-9-1 compliance. We're currently not
>> strictly spec compliant with 0-9-1 as we will resend messages that
>> have been rolled back. 0-9 and 0-8 are... ambiguous... on this matter,
>> and I've been trying to retain current behaviour for them.
>>
>> However, it's a) a massive PITA and b) probably Not What You Want. If
>> you're rolling back a consume it's almost certainly because you can't
>> cope with the message.
>>
>> If you think b) I'd like to float the idea of 0.8 being the "we are
>> breaking backwards compatibility" release so we can fix the conf file,
>> the command line etc.
>>
>> Thoughts?
>
> I don't read the spec in the same way.
>
> From the 0-9-1 Spec:
> 1.9.2.5. Method tx.rollback (ID 30)
> This method abandons all message publications and acknowledgments
> performed in the current
> transaction. A new transaction starts immediately after a rollback.
> Note that unacked messages will not be
> automatically redelivered by rollback; if that is required an explicit
> recover call should be issued.
>
> I read that as the unacked messages will not be automatically given
> back to the client. So we should put them back on the queue and let
> the client fight it out with other cilents to see who gets them.
My understanding is that they would remain in the 'acquired' state, not
acked but not requeued. The client could then decide to call recover
explicitly to either requeue them or have them redelivered (or it could
simply replay them itself if held locally).
In 0-8/0-9 it was not explicitly stated that there should be a
recover(requeue=false) implied by rollback but we assumed this as the
spec did prohibit an explicit recover call for transactional sessions.
0-9-1 explicitly stated that the recover was not implied, but allowed
the recover to be called on a transactional session if desired.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] transaction handling
Posted by Martin Ritchie <ri...@apache.org>.
On 1 April 2010 01:26, Aidan Skinner <ai...@gmail.com> wrote:
> I've recently been wrestling with transaction handling in the java
> broker in the context of 0-9-1 compliance. We're currently not
> strictly spec compliant with 0-9-1 as we will resend messages that
> have been rolled back. 0-9 and 0-8 are... ambiguous... on this matter,
> and I've been trying to retain current behaviour for them.
>
> However, it's a) a massive PITA and b) probably Not What You Want. If
> you're rolling back a consume it's almost certainly because you can't
> cope with the message.
>
> If you think b) I'd like to float the idea of 0.8 being the "we are
> breaking backwards compatibility" release so we can fix the conf file,
> the command line etc.
>
> Thoughts?
I don't read the spec in the same way.
>From the 0-9-1 Spec:
1.9.2.5. Method tx.rollback (ID 30)
This method abandons all message publications and acknowledgments
performed in the current
transaction. A new transaction starts immediately after a rollback.
Note that unacked messages will not be
automatically redelivered by rollback; if that is required an explicit
recover call should be issued.
I read that as the unacked messages will not be automatically given
back to the client. So we should put them back on the queue and let
the client fight it out with other cilents to see who gets them. It is
just a case that the client that does rollback will not be given a
second opportunity to consume those messages. This is what we
currently do in the Java broker.
This differs from JMS Client Ack Recover which calls Basic.Recover
which does resend all the unacked messages so the client is
guarranteed to get the same messages as the first time through.
So given a transacted client that consumes messages then rolls back
are you suggesting that the spec says that the client should not be
able to receive the messages that it had been given in the transaction
it rolled back?
Martin
> - Aidan
> --
> Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
> "A witty saying proves nothing" - Voltaire
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org