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

Tom Jenkinson (JIRA) issues at jboss.org
Tue May 15 04:38:00 EDT 2018


     [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-3020:
--------------------------------
    Forum Reference: https://developer.jboss.org/message/982097, https://javaee.groups.io/g/jta-spec/topic/suggestion_for_a_2pc/18102512  (was: https://developer.jboss.org/message/982097)


> 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
>             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.5.0#75005)


More information about the jbossts-issues mailing list