[
https://issues.apache.org/jira/browse/AMQ-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13920921#comment-13920921
]
Gary Tully commented on AMQ-3305:
---------------------------------
reworked changes in
http://git-wip-us.apache.org/repos/asf/activemq/commit/cfe099d1 to avoid the
need to flush the cursor on completion. This avoids duplicate (dispatch or dlq
processing) and also ensures that message add completions interleaved with new
messages are not skipped.
> Implement "exactly once" delivery with kahaDB and XA in the event of a
> failure post prepare
> -------------------------------------------------------------------------------------------
>
> Key: AMQ-3305
> URL: https://issues.apache.org/jira/browse/AMQ-3305
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Message Store
> Affects Versions: 5.5.0
> Environment: XA (with Geronimo for TM in the camel route test)
> Reporter: Gary Tully
> Assignee: Gary Tully
> Labels: 2pc, XA, camel, geronimo
> Fix For: 5.6.0
>
>
> With XA 2PC, a camel route, jms 'to' jdbc should ensure exactly once delivery
> to jdbc. In the event of a failure after prepare, where commit to jdbc is
> done, the jms message must remain with a pending ack till the commit outcome
> is relayed from the transaction manager.
> Current versions of geronimo will correctly retry the commit in a timer
> thread, so activemq eventually gets the commit outcome after recovery. (btw:
> it looks like howl will not persist a commit outcome per NamedXAResource, so
> after a failure of the TM it may consier the transaction completed and the
> message may still be pending, need to check that!)
> At the moment, ActiveMQ does a heuristic rollback after recovery which leads
> to message redelivery in error.
> With the fix, an acked message remains pending awaiting the outcome. On
> commit, the message is acked. On rollback the message is available for
> redelivery.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
