[
https://issues.apache.org/jira/browse/QPID-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843305#action_12843305
]
Steve Huston commented on QPID-2420:
------------------------------------
This problem arose because the original MS SQL store module runs a dtx's
operations under an outer SQL transaction and commits the SQL transaction on
dtx commit; thus, a prepare followed by a crash loses the SQL transaction and
any record of the dtx.
To fix this, here's what I think should be done:
Table changes:
1. The store maintains a SQL table of messageId->queueId mappings, one for each
place the message is queued. This table will have two more columns added:
add/remove (Boolean; true =add, false=remove) and xid (reference to TPL table's
xid key column).
2. Add a new table TPL with prepared Xids. The xid is the key and is referred
to by the new xid column in the message mapping table.
Behavior changes:
- When a dtx start is received (in the store, not in AMQP) a SQL transaction is
started and a new TPL record is added with the xid.
- On enqueue() add the message mapping record for the operation, and include
the 'add' indicator and dtx's xid
- On dequeue() add the xid to the existing mapping record and ensure the
add/remove field is 'remove'
- When dtx prepare is received in the store, commit the outer SQL transaction
from dtx start
- For dtx commit, under SQL transaction
1. Remove the xid record from the TPL table
2. For each mapping record that refers to the xid: delete 'remove' records,
remove xid and clear 'add' indicator from add records.
- For dtx rollback, under SQL transaction
1. Remove the xid record from the TPL table
2. For each mapping record that refers to the xid: delete 'add' records;
remove xid value from 'remove' records.
- On recovery
1. Read all the xids from the TPL table; there's one for each prepared dtx;
call recoverTransaction for each
2. For each xid, get the mapping records associated with the xid; based on
the add/remove indicator, call either RecoverableTransaction::enqueue() or
dequeue()
> Windows SQL-based persistence loses prepared two-phase transactions on broker
> restart
> -------------------------------------------------------------------------------------
>
> Key: QPID-2420
> URL: https://issues.apache.org/jira/browse/QPID-2420
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.6
> Environment: Windows, SQL
> Reporter: Steve Huston
> Assignee: Steve Huston
> Fix For: 0.7
>
>
> If the C++ broker restarts after a 2PC transaction is prepared but not
> committed, the transaction is lost (as if an abort was done on the
> transaction) when the broker restarts.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
