]
Michael Musgrove updated JBTM-3020:
-----------------------------------
Fix Version/s: 5.next
(was: 5.10.2.Final)
Add ability for resources to indicate XA_RDONLY on end
------------------------------------------------------
Key: JBTM-3020
URL:
https://issues.redhat.com/browse/JBTM-3020
Project: JBoss Transaction Manager
Issue Type: Feature Request
Reporter: David Lloyd
Assignee: Ondrej 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.