jta-spec
  1. jta-spec
  2. JTA_SPEC-4

support explicit ordering of commits for XAResources enlisted in a transaction

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      As reported here: http://java.net/jira/browse/JMS_SPEC-28 (and originally here: http://java.net/jira/browse/JAVAEE_SPEC-1) :

      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.

        Activity

        Hide
        irobins added a comment -

        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.

        Show
        irobins added a comment - 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.
        Hide
        tomjenkinson added a comment -

        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:
        http://jbossts.blogspot.co.uk/2011/04/messagingdatabase-race-conditions.html.
        However, 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.
        For example, if we do not wait for the commit completion message (either XA_OK or a heursitic) the user will still need to add business logic to compensate for data unavailability which would be unexpected and (in my mind) undermine the value of the feature should the programmer be expecting an "explicit ordering of commits" (I allow heurisics as this feature does not mention it is intended to address heurisitic outcomes).
        For example, consider a database (DB) and message broker (MQ) resource pair where you want the DB to commit first so the MQ can view the revised state:
        DB.prepare()
        MQ.prepare()
        tm.log();
        DB.commit() -> returns XAER_RMFAIL
        MQ.commit() -> business logic fails as expected db rows are not yet committed
        DB.commit(retried)

        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).
        For example if certain XAResources are more "probable" to fail, a developer may wish to attempt those first. However, if this is the intended use case, I think that the feature would be better described as "support explicit ordering of prepares for XAResources enlisted in a transaction", or possibly "support explicit ordering of commit attempts for XAResources enlisted in a transaction".

        Show
        tomjenkinson added a comment - 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: http://jbossts.blogspot.co.uk/2011/04/messagingdatabase-race-conditions.html . However, 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. For example, if we do not wait for the commit completion message (either XA_OK or a heursitic) the user will still need to add business logic to compensate for data unavailability which would be unexpected and (in my mind) undermine the value of the feature should the programmer be expecting an "explicit ordering of commits" (I allow heurisics as this feature does not mention it is intended to address heurisitic outcomes). For example, consider a database (DB) and message broker (MQ) resource pair where you want the DB to commit first so the MQ can view the revised state: DB.prepare() MQ.prepare() tm.log(); DB.commit() -> returns XAER_RMFAIL MQ.commit() -> business logic fails as expected db rows are not yet committed DB.commit(retried) 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). For example if certain XAResources are more "probable" to fail, a developer may wish to attempt those first. However, if this is the intended use case, I think that the feature would be better described as "support explicit ordering of prepares for XAResources enlisted in a transaction", or possibly "support explicit ordering of commit attempts for XAResources enlisted in a transaction".
        Hide
        Leos.Bitto added a comment -

        "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.

        Show
        Leos.Bitto added a comment - "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.
        Hide
        mmusgrove added a comment -

        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.

        Show
        mmusgrove added a comment - 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.
        Hide
        Leos.Bitto added a comment -

        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).

        Show
        Leos.Bitto added a comment - 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).

          People

          • Assignee:
            Unassigned
            Reporter:
            paul_parkinson
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: