You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org> on 2007/01/30 17:53:33 UTC

[jira] Assigned: (QPID-142) Transactions not atomic in the face of fail over

     [ https://issues.apache.org/jira/browse/QPID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marnie McCormack reassigned QPID-142:
-------------------------------------

    Assignee: Robert Greig

> Transactions not atomic in the face of fail over
> ------------------------------------------------
>
>                 Key: QPID-142
>                 URL: https://issues.apache.org/jira/browse/QPID-142
>             Project: Qpid
>          Issue Type: Bug
>          Components: Dot Net Client, Java Client
>            Reporter: Steven Shaw
>         Assigned To: Robert Greig
>
> When some messages are already published in a transaction when fail over occurs, those messages will be lost.
> Options seem to be:
>   1. Remembering and replaying sent messages (in a Tx)
>   2. Aborting any in-flight transactions on failover
> 1 could be costly in terms of memory for applications using transaction. 2 could be annoying for applications requiring the use of retry loops (however these retry loops are often necessary in any case and can sometimes be injected via AOP).
> I asked Gordon's opinion and he favored (2) as well.
> In addition to this we need to ensure that the broker issues a Channel.Close when it gets a Tx.Commit without a prior Tx.Select. It's not clear what error code should be used. Invalid-command (503) looks close but is a hard-error. Check the amqp-dev list for discussion on this topic.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.