[
https://issues.apache.org/jira/browse/QPID-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274001#comment-13274001
]
[email protected] commented on QPID-3990:
-----------------------------------------------------
bq. On 2012-05-12 00:01:58, rajith attapattu wrote:
bq. > Based on the description of the problem and the proposed solution the
code appears to be doing whats expected.
bq. > There are a few whitespace errors that could be removed. On eclipse
ctr-a and ctr-i should take care of it provided you have set tabs to whitespace.
bq. >
bq. > For my own understand, could you please explain if there could be any
implications/corner cases when a particular XAResource calls start and end on
the other XAResources participating in the transaction even though they are all
managed by the same Resource Manager. In particular is there some sort of
ordering that should be preserved when this is called? How about error
handling? What if one of the XAResources fail/throw exception when start or end
is called ?
bq. > (I assume under normal circumstances the RM would call these methods and
would be in a position to handle these situations. In the above case the
XAResource (all though being called by an RM) would act as a proxy for it's
siblings). Is my understanding correct ? If not are you able to briefly explain
the flow here ?
Good question. It's important to keep in mind in a typical XA flow, an
XAResource never calls anything on another XAResource as the TransactionManager
does this. However, as the original description mentions, the issue here is
that because the XAResources in question are on the same transaction branch,
the TM only calls start/end on the first XAResource discovered in the protocol
and as a result the other XAResources are not allowed to complete correctly.
Another way to put this is that doing correctly support joining multiple
XAResources in the same transaction from the same ResourceManager (Broker).
The isSameRM method provides a convenient place to 'intercept' the XA flow
being that the TM always calls this when another XAResource is being enlisted
in the transaction. Because of this fact, the correct order will always be
maintained, however, a good test case would be more than two XAResources. I
will add this.
Again, this 'fix' is simply to address what is either a discrepancy between the
XA and AMQP specs, or an incorrect implementation on the Broker (both Java and
C++). It's not ideal, but currently if we don't provide some sort of solution,
and code involving multiple XAResources from the same Broker will not work at
all which, in my opinion has severe consequences beyond introducing a fix in
the JMS/JCA code.
- Weston
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5079/#review7820
-----------------------------------------------------------
On 2012-05-09 17:41:59, Weston Price wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/5079/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2012-05-09 17:41:59)
bq.
bq.
bq. Review request for Ted Ross, Robbie Gemmell, rajith attapattu, and Rob
Godfrey.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. In fixing QPID-3263, an issue has cropped up when two XAResources have the
same underlying ResourceManager(RM). Originally the isSameRM method returned
false regardless of whether or not the RMs were the same. Since we now return
true when two or more XAResources are involved, we get an ILLEGAL_STATE
exception being that the DtxStart/DtxEnd calls are not paired for each
XAResource because the TransactionManager (TM) treats the XAResource(s) as
being on the same transaction branch. As a result, DtxEnd is only called on one
resource.
bq.
bq. While it might make sense to simply roll back to the old behavior, this is
not going to perform as well being that most TM's can optimize underlying
transaction state with isSameRM is true. This has performance implications for
the TM in terms of logging, management etc.
bq.
bq. The following patch/diff allows XAResources to be aware of each other in a
transaction chain. When DtxEnd is called on one resource, the sibling
XAResources.end method is called thereby matching the DtxStart/DtxEnd
invocations appropriately allowing the transaction to complete.
bq.
bq.
bq. This addresses bug QPID-3990.
bq. https://issues.apache.org/jira/browse/QPID-3990
bq.
bq.
bq. Diffs
bq. -----
bq.
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQXAResource.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/XAResourceImpl.java
1336275
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAXAResource.java
1336275
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/jms/xa/XAResourceTest.java
1336275
bq.
bq. Diff: https://reviews.apache.org/r/5079/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Added system test to XAResourceTest to exercise new behavior. Tested
against both the Java and C++ Brokers using the 0.10 profile.
bq.
bq.
bq. Thanks,
bq.
bq. Weston
bq.
bq.
> Multiple XAResources isSameRM behavior
> --------------------------------------
>
> Key: QPID-3990
> URL: https://issues.apache.org/jira/browse/QPID-3990
> Project: Qpid
> Issue Type: Bug
> Components: Java Client, JCA
> Affects Versions: 0.14, 0.17
> Environment: All supported OS platforms. All supported JEE platforms.
> Reporter: Weston M. Price
> Assignee: Weston M. Price
> Priority: Critical
>
> In fixing QPID-3263, an issue has cropped up when two XAResources have the
> same underlying ResourceManager(RM). Originally the isSameRM method returned
> false regardless of whether or not the RM's were the same. Since we now
> return true when two or more XAResources are involved, we get an
> ILLEGAL_STATE exception being that the DtxStart/DtxEnd calls are not paired
> for each XAResource because the TransactionManager (TM) treats the
> XAResource(s) as being on the same transaction branch. As a result, DtxEnd is
> only called on one resource.
> According to Gordon, this may be a discrepancy between XA and the AMQP .10
> specification. This has inadvertently worked in the JCA code due to bug in
> the isSameRM method and the use of the QpidRAXAResourceWrapper.
> While it might make sense to simply roll back to the old behavior, this is
> not going to perform as well being that most TM's can optimize underlying
> transaction state with isSameRM is true. This has performance implications
> for the TM in terms of logging, management etc.
> I have a fix for this issue that allows XAResources to be aware of each other
> in a transaction chain. When DtxEnd is called on one resource, the sibling
> XAResources.end method is called thereby matching the DtxStart/DtxEnd
> invocations appropriately allowing the transaction to complete.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
