1 2 Previous Next 21 Replies Latest reply on Aug 15, 2014 8:53 AM by jesper.pedersen

    Proposed SPI change to XAResourceWrapper

    mmusgrov

      I would like to add an extra method to org.jboss.tm.XAResourceWrapper so that we can look up the resource manager id of the RM that created the wrapped resource. We need it since, in the case of hornetq, the jndi name does not necessarily uniquely identify the resource (https://issues.jboss.org/browse/JBTM-2230). The additional interface method is:

       

         /**

          * Get the XA RM id corresponding to the resource manager that created this resource.

          * This meta data is useful for RMs that do not guarantee unique JNDI names but

          * can guarantee that the combination of jndi name and RM id uniquely identifes a resource.

          * @return The value if defined; otherwise <code>null</code>

          */

         public String getResourceManagerId();

       

      We have a number of projects using the SPI but only irnonjacamar implements org.jboss.tm.XAResourceWrapper. This post is to give any potential users a heads up that they will *not* be able to upgrade jboss-transaction-spi until they implement the extra method (but note that returning null is just fine if the project knows that jndi name suffices for uniqueness).

       

      FYI as far as can see the only wildfly usages of jboss-transaction-spi are as follows (and out of this list only ironjacamar-core-impl seems to be affected):

       

      ironjacamar-core-impl

      hornetq-jms-server

      jboss-as-clustering-infinispan

      jboss-as-clustering-web-infinispan

      jboss-as-cmp

      jboss-as-connector

      jboss-as-ejb3

      jboss-as-jpa

      jboss-as-messaging

      jboss-as-transactions

        • 1. Re: Proposed SPI change to XAResourceWrapper
          tomjenkinson

          Thanks for the discussion entry Mike, jesper.pedersen might have some input for us.

           

          Here is the scenario that the JNDI doesn't work for HQ for:

           

          1. prepare JMS java:jmsXa,Xid1 (true RM ID is abc)

          2. prepare DB name2,Xid2

          3. prepare TX log (write java:jmsXa,Xid1 and name2,Xid2)

          4. commit JMS java:jmsXa,Xid1 -> returns HEURISTIC_ROLLBACK

          5. crash

          6. recover TX

          7. recover JMS java:jmsXa (true RM ID is xyz though, so it returns no Xid as its a different RM)

          8. recover DB name2 (returns name2,Xid2)

          9. As java:jmsXa matches but the true RM ID are different, it means we will commit DB name2 assuming the JMS resource completed OK when we should have rolled it back

           

          Normally if the HQ server is collocated in the WildFly instance this would not affect us and the following scenario would occur:

           

          1. prepare JMS java:jmsXa,Xid1 (true RM ID is abc)

          2. prepare DB name2,Xid2

          3. prepare TX log (write java:jmsXa,Xid1 and name2,Xid2)

          4. commit JMS java:jmsXa,Xid1

          5. crash

          6. recover TX

          7. recover JMS java:jmsXa (true RM ID is still abc which returns no Xid)

          8. recover DB name2 (returns name2,Xid2)

          9. Don't want to print no XA resource to recover java:jmsXa,Xid1, if we can match up java:jmsXa reliably we can infer that JMS java:jmsXa committed pre crash

          • 2. Re: Proposed SPI change to XAResourceWrapper
            ataylor

            for the case where IronJacamar wraps a HornetQ XA resource in a wrapper we need a way of returning this infor from HornetQ. Maybe if we return a warpped resource in our ManagedConnection implementation then IronJacamar could simply use this, Jesper?

            • 3. Re: Proposed SPI change to XAResourceWrapper
              mmusgrov

              IJ has an option to disable wrapping resources (by setting wrap-xa-resource to false in the XA pool element of the datasource config). If you pass a wrapped resource and this setting is false should IJ then unwrap what you provided them with?

              • 4. Re: Proposed SPI change to XAResourceWrapper
                martyn-taylor

                "This meta data is useful for RMs that do not guarantee unique JNDI names but can guarantee that the combination of jndi name and RM id uniquely identifes a resource."

                 

                Does the unique identifier need to be a pair of jndi + resource manager id?  Or is a unique ID of the RM such as a UUID sufficient?  If TM needs a combination of jndi name + resource manager ID, then my vote is to add this extra method to existing XAResourceWrapper interface. 


                Otherwise I'd vote for adding this to a separate optional interface that is implemented only in RMs where this is required.  This reduces impact across other projects such as IronJacamar and also means that RMs implementing this getResourceManagerId() method are not required to implement the existing XAResourceWrapper.

                • 5. Re: Proposed SPI change to XAResourceWrapper
                  jesper.pedersen

                  For JCA resources the jndi name is unique for ConnectionFactory's, and for inflow the configuration of the ResourceAdapter instance is unique.

                   

                  So, there is no need from here to add it, but feel free to do so.

                  • 6. Re: Proposed SPI change to XAResourceWrapper
                    jesper.pedersen

                    Andy, if you implement the IronJacamar TX SPI (similar to the Narayana SPI) you can pass the XAResourceWrapper instance from the underlying ManagedConnection directly. Although I can see there is a bug there atm - easy fix

                    • 7. Re: Proposed SPI change to XAResourceWrapper
                      jesper.pedersen

                      Mike, if wrap-xaresource is false the XAResource instance from the ManagedConnection is passed directly.

                      • 8. Re: Proposed SPI change to XAResourceWrapper
                        mmusgrov

                        After discussions with Martin I have had second thoughts about my proposal to add another method to the XAResourceWrapper interface. To summarise, the purpose of getJndiName is twofold:

                        • being able to report something meaningful to admins if we can't locate an XAResource for a branch;
                        • being able to uniquely match up a transaction log record with an XAResource.

                         

                        From the TMs point of view the datum is opaque data which satisfies both requirements (ie we don't use it to interact with any other interface).

                         

                        Now, we thought that the JNDI name was good enough for both purposes but it turns out this is not so in the JMS case. However, adding the second method to the wrapper will lead to confusion - we now have two methods for determining uniqueness. If we stick with my current proposal Martyns approach is to give us something unique in the new method whilst clearly we must continue to use JNDI name for everything else. Not a good interface design.

                         

                        So my new proposal is to keep to the original interface (perhaps updating the javadoc) and make sure JMS gives us something unique in getJndiName as follows:

                        • in the JMS subsystem config you add an attribute called jndi-prefix to each of the entries in each connection-factory (Andy can you confirm if that is the correct element to add it to);
                        • when JMS creates an XAResource it tacks on the RM id (or whatever is appropriate for you to guarantee uniqueness)

                         

                        This gives the admin something to go on for debugging issues and a benefit for the hornetq team is that registration in the JNDI tree is optional (in fact it serves no purpose).

                         

                        Finally, it is worthwhile pointing out that XAResourceWrapper is our (as in narayana TM) SPI and is for use internally (to IJ and wildfly) and is not a general purpose SPI for foreign app servers to integrate narayana.

                        • 9. Re: Proposed SPI change to XAResourceWrapper
                          marklittle

                          OK so does this mean you can close the associated JIRA?

                          • 10. Re: Proposed SPI change to XAResourceWrapper
                            martyn-taylor

                            Jesper.  Does the bug you mentioned live in IronJacamar?  Is this now fixed?

                            • 11. Re: Proposed SPI change to XAResourceWrapper
                              ataylor

                              Now, we thought that the JNDI name was good enough for both purposes but it turns out this is not so in the JMS case. However, adding the second method to the wrapper will lead to confusion

                              Im not sure I agree Mike, confusion for who. surely as someone implementing getJndiName() they would expect to return the jndi name and nothing else in their impl. how is adding a second method getUniqueId() confusing, I would actually say it is less confusing. How you use these methods in your code is a TM implementation detail?

                               

                              Saying that if fixing your API is a pita to do we will go with just the jndi name with a change to your javadocs like you mentioned.

                              • 12. Re: Proposed SPI change to XAResourceWrapper
                                mmusgrov

                                Andy Taylor wrote:

                                 

                                Now, we thought that the JNDI name was good enough for both purposes but it turns out this is not so in the JMS case. However, adding the second method to the wrapper will lead to confusion

                                Im not sure I agree Mike, confusion for who. surely as someone implementing getJndiName() they would expect to return the jndi name and nothing else in their impl. how is adding a second method getUniqueId() confusing, I would actually say it is less confusing. How you use these methods in your code is a TM implementation detail?

                                 

                                Saying that if fixing your API is a pita to do we will go with just the jndi name with a change to your javadocs like you mentioned.

                                I would argue that our API doesn't need fixing and that you need to correctly register your resource in the JNDI tree.

                                • 13. Re: Proposed SPI change to XAResourceWrapper
                                  ataylor

                                  I would argue that our API doesn't need fixing and that you need to correctly register your resource in the JNDI tree.

                                  what do you mean correctly register the resource, we do, but what a connection factory is registered as is not a unique identifier. Im saying that if the jndi name of the pooled connection factory is "java:/JmsXA" then getJndiName() should return this not "java:/JmsXAsomeuniquenodeid", that should be returned by getJndiName() + getUniqueId().

                                   

                                  saying that, like i said, we are happy to make do with your broken API

                                  • 14. Re: Proposed SPI change to XAResourceWrapper
                                    marklittle

                                    Guys, handbags at dawn

                                     

                                    images.jpeg

                                    1 2 Previous Next