[
https://issues.apache.org/jira/browse/QPID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468843
]
John O'Hara commented on QPID-142:
----------------------------------
Agree 2 is the *only* way to go.
It's what every other technology I've seen does -- there is no way to reliable
continue a current transaction after a failure (even Oracle RAC can't do it,
except for some cheating with r/o queries).
However, I don't think sending a Failover Exception is at all viable. If
you're failing, you don't (normally) expect it. So there will be no warning.
It is possible that for admin reasons you could issue a administrative
failover; but I would warn against that. It provides more optionality on the
code paths, which provides more opportunity for errors on both the client and
the server.
We must be draconian about always knowing the state of the client and server.
Any indeterminate state must assume a failure.
- it either works, or it doesn't work. No in-betweens.
John
> 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.
