|<< Back to previous view|
[JTA_SPEC-4] support explicit ordering of commits for XAResources enlisted in a transaction Created: 20/Aug/12 Updated: 30/Aug/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Participants:||irobins, Leos.Bitto, mmusgrove, paul_parkinson and tomjenkinson|
Currently there is no standard way how to enforce the ordering of the XAResource commits for the transaction. There are workarounds such as http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/Transactions_Development_Guide/chap-Transactions_JTA_Programmers_Guide-Test.html#form-Transactions_JTA_Programmers_Guide-The_XAResource_Interface-Extended_XAResource_control for example, but I think that a properly specified standard API would be much better.
|Comment by irobins [ 30/Sep/12 01:45 PM ]|
There are some good reasons for wanting to do this but there are other ways to accomplish it than extending XAResource. One way (we did this as a WebSphere vendor extension) is as an extension to the resource-reference. We found this a simple way to enable different apps to use resources in different orders without polluting any runtime beyond the TM and ConnectionManager.
|Comment by tomjenkinson [ 04/Nov/12 09:48 PM ]|
Please can you clarify the use case that this feature is intended to address? I think that there are at least two interpretations of what this Jira could be intended to address:
The first interpretation I see is that we will support explicit ordering of commit completions (we won't move on to the next resource until we receive any true completion value, i.e. any value that is not an XAER_RMFAIL). A feature like this would be able to address use cases such as "race conditions". There is a good article describing race conditions of XAResources here:
The second interpretation I see could be that we will support explicit ordering of commit attempts. In this case we would move onto the next resource regardless of the result of the current XAResource.commit(). A feature like this can support use cases that do not couple the transaction manager to the business logic (i.e. in the event of a commit failure, the transaction manager is still at liberty to move on to higher ordered XAResources).
|Comment by Leos.Bitto [ 04/Nov/12 10:01 PM ]|
"providing a capability to address the issues discussed in that article would require the Transaction Manager to wait for completed commits (i.e. retry the commits for resources returning XAER_RMFAIL before moving on to higher order XAResources). This would couple the transaction manager into the business logic which is not desirable." - I think that if the users explicitly state that they want the ordering of the XAResource commits (for example DB first, JMS later), then the Transaction Manager should simply obey this. Such coupling of TM to the business logic is quite light in my opinion, and it is fully justified by the fact that otherwise the race conditions between the JMS commit and the DB commit have to be handled in the user code, which is ugly.
|Comment by mmusgrove [ 30/Aug/13 07:23 AM ]|
Please could we also include Synchronizations in this discussion. I know we already have limited ordering semantics with interposed synchronizations as standard but we have had other ordering requirements from the JCA (and I think JPA) teams within the wildfly application server. What I'd like to see is an interface that allows us to order some synchronisations relative to each other and allow others to run as normal - ie the synchronisations would form a partially ordered set where we have the choice to run independent partial orders in parallel.
|Comment by Leos.Bitto [ 30/Aug/13 08:03 AM ]|
I don't think that adding more requirements to this Jira issue is a good idea because that it has been originally reported in December 2011, it is still not resolved and there is not even any progress visible. Regarding Synchronizations there actually is an easy solution: register only one Synchronization which would be implemented to allow runnning other Synchronizations with any order you like (composite pattern).