[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end
by Tom Jenkinson (Jira)
[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-3020:
-------------------------------------
Good point, it works with AbstractRecord, In that case perhaps we could use XAResourceWrapper in the https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... to alter the order() (and add a resort of the list before calling prepare) perhaps just add a method to it: prepareWillBeRDONLY()
> 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)
5 years, 5 months
[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-3020:
----------------------------------------
We can change the implementation of XAResourceRecord#order() to check whether or not the resource implements Comparator.
> 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)
5 years, 5 months
[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka commented on JBTM-3020:
---------------------------------------
But my understanding was that the {{XAResource}} is directly bound to the {{XAResourceRecord}}. The code of {{BasicAction}}, which can influence the logic of who will be prepared and who will not be, works with {{XAResourceRecord}}s. Or not?
> 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)
5 years, 5 months
[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end
by Tom Jenkinson (Jira)
[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-3020:
-------------------------------------
My suggestion is just for XAResources in fact
> 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)
5 years, 5 months
[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ]
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)
5 years, 5 months
[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka commented on JBTM-3020:
---------------------------------------
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)
5 years, 5 months
[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end
by Tom Jenkinson (Jira)
[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-3020:
-------------------------------------
I am thinking, to achieve the same effect perhaps we can just allow XAR to implement https://docs.oracle.com/javase/7/docs/api/java/util/Comparator.html.
Any XAR that implements this would by default go before other XAR during prepare
We would sort the list before calling prepare on them.
Anything that knows it is going to return RDONLY in prepare can return -1 at that time, ideally leaving the other one (perhaps returning 0).
> 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)
5 years, 5 months
[JBoss JIRA] (JBTM-3077) Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
by Shaun Appleton (Jira)
Shaun Appleton created JBTM-3077:
------------------------------------
Summary: Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
Key: JBTM-3077
URL: https://issues.jboss.org/browse/JBTM-3077
Project: JBoss Transaction Manager
Issue Type: Bug
Components: JTS
Environment: EAP 6.4.18
Reporter: Shaun Appleton
Description of problem:
Lock is held by EJB timer (TimerServiceImpl) and in case JTS transaction is cancelled the lock won't be released correctly . This code is the problem:
https://github.com/wildfly/wildfly/blob/78dee79dd0f49c6cbd2b8db5d8640980f...
Basically it holds the timer lock until the transaction completes, and then attempts to release it in afterCompletion. The problem is that when JTS is enabled afterCompletion will be called by a seperate thread, which can't call unlock as it is not the owner.
A simple fix could be to just change the lock to a semaphore, so that the other thread can release it.
Version-Release number of selected component (if applicable):
How reproducible:
Always
Steps to Reproduce:
1. Start a JTA/JTS tx and call an EJB timer inside it
2. Make the transaction timeout
3. Capture a thread dump and see a thread like below (0a0818b80 is locked object)
---------------------------------------------------------------------------------------------------------
"Incoming-2,RouterPoliciesClusterGroup,svc-3-comecimpolicy-59228 (, payload=52 bytes)" #661 prio=5 os_prio=0 tid=0x00007f5214c2d000 nid=0x1e67 waiting on condition [0x00007f520ac97000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000a0818b80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Locked ownable synchronizers:
- <0x00000000ea1f4c48> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
---------------------------------------------------------------------------------------------------------
Actual results:
Lock being held forever
Expected results:
Lock getting released
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months