[jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end

[Ondra Chaloupka (Jira)]

    [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662193#comment-13662193 ] 

Ondra Chaloupka edited comment on JBTM-3020 at 11/15/18 12:38 PM:
------------------------------------------------------------------

I'm worry it's not so straighforward. The {{com.arjuna.ats.arjuna.coordinator.AbstractRecord}} already defines the ordering methods like {{equals}}, {{lessThan}}... and the ordering is complicated as Jonathan mentioned at the forum (https://developer.jboss.org/message/983601#983601).


was (Author: ochaloup):
I'm worry it's not so straighforward. The {{com.arjuna.ats.arjuna.coordinator.AbstractRecord}} already defines the ordering methods like {{equals}}, {{lessThan}}... and the ordering depends on what Jonathan mentioned in the forum (https://developer.jboss.org/message/983601#983601).

> Add ability for resources to indicate XA_RDONLY on end
> ------------------------------------------------------
>
>                 Key: JBTM-3020
>                 URL: https://issues.jboss.org/browse/JBTM-3020
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>            Reporter: David Lloyd
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 5.next
>
>
> As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring.
> As expressed in the forum thread, the mechanism should not interfere with compatibility.  One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this:
> {code:java}
>     int endWithResult(Xid xid, int flags) throws XAException;
> {code}
> The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}.  A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}.  An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method.  {{XAER_RMERR}} seems like a reasonable error code for this case.  An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}.
> Since it's a subinterface of {{XAResource}}, it could also define the following default method:
> {code:java}
>     default void end(Xid xid, int flags) throws XAException {
>         endWithResult(xid, flags);
>     }
> {code}
> This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)