1 2 3 4 5 Previous Next 72 Replies Latest reply on May 14, 2010 11:40 AM by jesper.pedersen Go to original post
      • 30. Re: JcaXAResourceRecovery

        Explain the problem with the data being elsewhere. Due to the nature of the data and the fact that it cannot be saved by the jca layer in general, it has to be elsewhere. If its the current security integration you are really complaining about, define your own abstraction ala the Subject factory suggested by Adrian.

        • 31. Re: JcaXAResourceRecovery

          Were any JIRA issues created from this thread?

          I've just closed the issues that were raised for the now obsolete old TM

          • 32. Re: JcaXAResourceRecovery

            Right, time for a spot of thread necromancy...

            How is this going to work in AS 5.0? Having parts of the app server be aware of the recovery implementation in JBossTS is nasty. Likewise for having JBossTS be configured with recovery information for e.g. xa-datasource deployments in the AS.

            Personally I'd like to see an extension of the transactions spi to encompass an interface through which recovery information could be registered with the transaction manager.

            The alternative would seem to be holding that information on the AS side and defining the way in which the transaction manager accesses it.

            • 33. Re: JcaXAResourceRecovery

              With the MC in JBoss5 we could do something like the following:

              NOTE: I allow mutlple XAResources because of the ResourceAdapter
              But it would be the job of our Resource Adapter deployment to add
              the known activation specs, i.e. those that have been activated.

              package org.jboss.tm; // in jboss integration
              public interface XAResourceRecovery
               XAResource[] getXAResources();

              You would then have methods:
              public void addXAResourceRecovery(XAResourceRecovery recovery) {}
              public void removeXAResourceRecovery(XAResourceRecovery recovery) {}

              The wiring can then either be done manually (including programmatically - see MBeans below)
              <bean "MyConnectionManager" ...>
               <install bean="TMService" method="addXAResourceRecovery">
               <uninstall bean="TMService" method="removeXAResourceRecovery">

              or "automagically" by you asking to be injected with any bean
              that implements the interface.

              <bean name="TMService" ...>
               <incallback method="addXAResourceRecovery"/>
               <uncallback method="removeXAResourceRecovery"/>

              The automagic approach is less error prone, but doesn't work with MBeans.


              For the old MBeans it would have to do something like:

              <mbean ...>
               <attribute name="TMService><inject bean="TMService"/></attribute>
              public void startService() throws Exception
              public void stopService() throws Exception


              The construction of the XAResource (including the injection
              of a "Recovery Subject" from the security config - see above) would
              be handled by whoever implements the XAResourceRecovery.

              • 34. Re: JcaXAResourceRecovery

                I guess your job is to create the interface in the jboss integration project and
                add/implement the add/remove methods in the transaction manager service.

                That's the easy bit (but only because you've already implemented the
                much harder problem - the recovery itself. :-)

                We can then implement this interface in the TxConnectionManager and
                ResourceAdapterDeployment (which are boths MBeans so they would
                have to do the manual installs in the MBean lifecycle methods).

                • 35. Re: JcaXAResourceRecovery


                  "adrian@jboss.org" wrote:
                  I guess your job is to create the interface in the jboss integration project and
                  add/implement the add/remove methods in the transaction manager service.

                  You also want to create an interface
                  package org.jboss.tm;
                  public interface XAResourceRecoveryRegistry
                   void addXAResourceRecovery(XAResourceRecovery recovery);
                   void removeXAResourceRecovery(XAResourceRecovery recovery);

                  so we can do typesafe injection into the MBean and not have to know the
                  implementation class.

                  • 36. Re: JcaXAResourceRecovery

                    Actually, it might be better to just implement a single XAResource
                    and get each MDB deployment to add/remove() via the resource adapter
                    rather than you trying to work out what changed in a list of XAResources.

                    It could also do with some kind of


                    to say you've finished with the XAResource and reclaim the resources
                    although that's currently an issue with the ResourceAdapter api. :-(

                    • 37. Re: JcaXAResourceRecovery

                      OK, I'm inclined to go with the XAResourceRecovery / XAResourceRecoveryRegistry outlined above for now and see how it works out. Changes to the contents of the array of resources between recovery passes may cause problems, but we'll revisit that if it does. I think it's more likely that the array will contain just a single resource in most cases though.

                      I also prefer to avoid a lifecycle for resources e.g. 'close()'. The existing recovery mechanism in JBossTS has lifecycle issues so I'm tending towards a stateless design at the moment if only because anything different is good :-) If a connector needs to clean up a resource for some reason it can just unregister and re-register. Short of stopping the recovery process, there is no reason why the transaction manager would ever be done with a resource. As long as the transaction server is alive it should keep querying periodically to see if there are any new problems. Paranoia is a good thing.

                      Adrian, I've checked in the new interface files to the integration trunk. Please look them over, modify if you wish and put out a new integration module release if you have time. Otherwise I'll try and figure out how to do it tomorrow.


                      • 38. Re: JcaXAResourceRecovery

                        Jonathan, I've looked your changes in integration over and agree that we should take the specified interface for the first release. We can revise the SPI if we find specific use-cases later on.

                        Feel free to add examples to the JBossTS documentation on how to inject the registry into other beans using the MC or JMX ;)

                        I've some small changes to the integration project that I'll commit and then do the CR1 release. The work is tracked through http://jira.jboss.com/jira/browse/JBAS-5288

                        Thanks for your effort in this area.

                        • 39. Re: JcaXAResourceRecovery


                          "jesper.pedersen" wrote:

                          Feel free to add examples to the JBossTS documentation on how to inject the registry into other beans using the MC or JMX ;)

                          You don't inject the registry. Instead your object is injected into the registry
                          because it implements the interface. See discussion above.

                          • 40. Re: JcaXAResourceRecovery

                            Yeah, sorry about that - I meant it the other way around as the discussion described it.

                            • 41. Re: JcaXAResourceRecovery

                              Hi guys

                              We are looking at ways of solving a current problem around recovery: it's not always clear which resource manager is misbehaving, which makes it difficult to know where to look for the source of the trouble.

                              All the transaction manager can do is print out the Xid, or the String representation of the XAResource if it's lucky and not actually crashed yet. But these structures contain little meaningful information for the user.

                              What we really want to know is the name of the Resource Manager that Resource belongs to i.e. the JNDI name or similar - something the user can relate back to a -ds.xml file or such.

                              To accomplish that the Transaction Manager either needs to be provided with the information up front (extra fields in the JcaXAResourceWrapper?) or have some way to ask the app server for it e.g. SomeIntegrationAPI.getJNDINameForXAResource(XAResource xar) or better still getJNDINameForXid(Xid xid)

                              Any thoughts on how we could go about providing this useful debugging aid?

                              • 42. Re: JcaXAResourceRecovery

                                The current solution of depending on the JcaXAResourceWrapper class located inside the JCA implementation will not work over time. The current class in AS-5.0 is called XAResourceWrapper, but provides the same functionality as the old JcaXAResourceWrapper class.

                                I think that we should put the wrapper classes (XAResourceWrapper / XidWrapper (JcaXid)) in the JCA SPI, so you can depends on them there.

                                We could include some basic information in the XAResourceWrapper that would identify which resource archive the recovery currently is processing - like the EISProductName and EISProductVersion for starters.

                                Later on we can provide facilities in the JCA SPI to request more information about the XAResource or the Xid -- like getJNDIName(XAResouce) and getJNDIName(Xid). But I want to take a deeper look at the implementation of these methods before committing the project to implement them.

                                The first part of the post I could commit after the AS-5.0.CR1 release if you think it would benefit the users.

                                • 43. Re: JcaXAResourceRecovery

                                  > I think that we should put the wrapper classes (XAResourceWrapper / XidWrapper (JcaXid)) in the JCA SPI, so you can depends on them there.

                                  Perhaps not the classes, but a basic interface to the required information would be great. I'd definitely like to see that go into the transactions SPI sometime between 5.0 CR1 and GA. If we can use that to improve the diagnostic info available in the logs it will help a lot with customer support for transaction issues.

                                  • 44. Re: JcaXAResourceRecovery

                                    I'll look into this task as soon as CR1 is out.