1 2 3 Previous Next 72 Replies Latest reply on May 14, 2010 11:40 AM by jesper.pedersen

    JcaXAResourceRecovery

    weston.price

      I may have initially underestimated this task. The JcaXAResourceWrapper, by itself, is not sufficient for recovery integration. I have started on

      org.jboss.resource.connectionmanager.xa.JcaXAResourceRecovery
      


      for this purpose. It's easy enough to configure something like this for DataSources such as

      <property name="com.arjuna.ats.jta.recovery.XAResourceRecoveryJCA=org.jboss.resource.connectionmanager.xa.JcaXAResourceRecovery;DSNAME1, DSNAM2"/>
      


      the issue I am not following is for DataSource and other JCA deployments that rely on a CRI, Subject etc. I would assume that for recovery purposes, a default connection of some sort will have to be provided by the client to allow JBossTS to do it's job. This would seem to suggest that we are now at the very least going to force a separate deployment for recovery if the default deployment cannot be accessed in this manner. The JMS example assumes the creation of a connection without JMS credentials so I am assuming I am in the same boat.

      I can't see any other way to do this unless we made them provide a separate configuration file for their resources that we could access that would allow me to recreate the underlying resource.



        • 1. Re: JcaXAResourceRecovery
          weston.price

          I believe that the configuration file approach is the *easiest* way to accomplish this. Assuming that a client specifies all the relevant information in a file where I can recreate the underlying connection and then the XAResource this would seem to be pretty straightforward.

          The DSName of course is not going to mean a f*@#$*! thing and I don't even know why I brought it up. No way to really obtain the XAResource from there anyway...sheer stupidity on my part.


          • 2. Re: JcaXAResourceRecovery
            timfox

             

            "weston.price@jboss.com" wrote:
            I may have initially underestimated this task. The JcaXAResourceWrapper, by itself, is not sufficient for recovery integration. I have started on

            org.jboss.resource.connectionmanager.xa.JcaXAResourceRecovery
            


            for this purpose. It's easy enough to configure something like this for DataSources such as

            <property name="com.arjuna.ats.jta.recovery.XAResourceRecoveryJCA=org.jboss.resource.connectionmanager.xa.JcaXAResourceRecovery;DSNAME1, DSNAM2"/>
            


            the issue I am not following is for DataSource and other JCA deployments that rely on a CRI, Subject etc. I would assume that for recovery purposes, a default connection of some sort will have to be provided by the client to allow JBossTS to do it's job. This would seem to suggest that we are now at the very least going to force a separate deployment for recovery if the default deployment cannot be accessed in this manner. The JMS example assumes the creation of a connection without JMS credentials so I am assuming I am in the same boat.

            I can't see any other way to do this unless we made them provide a separate configuration file for their resources that we could access that would allow me to recreate the underlying resource.



            When I wrote the ResourceRecovery instance for the JMS bridge, it gets its config from a properties file, which also (optionally) contains the username and password to create the XAConnection to get the XASession and XAResource.


            • 3. Re: JcaXAResourceRecovery
              timfox

              Also, one thing I noticed when doing the XA recovery work for JBM is that the JMSProviderXAResourceRecovery instance that was done for JBossMQ is broken.

              The way JBoss TS recovery manager works is as follows:

              It calls:

              myXAResourceRecovery.hasMoreResources()

              returns true

              myXAResourceRecovery.getXAResource()

              returns resource

              myXAResourceRecovery.hasMoreResources()

              returns false

              it then calls recover() as appropriate on the XAResoource

              and then commit/rollback as appropriate

              and then, and it *throws the XAResource away*

              then on the next time around (120 seconds later or whatever)

              it goes through the whole procedure again.

              The way the JBossMQ XAResourceRecovery was written is that it never returns true to hasMoreResources after the first time.

              So any in doubt transactions after that time will never be picked up.

              Also the concept of an XAResourceWrapper which will transparent reconnect doesn't make much sense to me, if you bear in mind the above. Since JBoss TS will throw away the Wrapper anyway after the pass.

              You may as well create a new one on each pass. (This is what we do) It certainly makes the code a lot simpler.

              • 4. Re: JcaXAResourceRecovery
                weston.price

                Yes. I am aware of how it works.

                For JCA resources this is not straightforward being that the underlying connection (and thus access to the XAResource) cannot always be easily recreated.

                In the recovery work for JBM, you simply pass the name of the JMSProviderAdapter to your RecoveryModule implementation which allows you to access the XAConnection->XASession->XAResource.

                In many cases in JCA deployments this isn't that straightforward for a variety of reasons:

                1) The underlying resource requires an authenticated Subject to be created

                2) The underlying resource requires programmatic user information (ConnectionRequestInfo) that is not supplied in the deployment.

                3) Unlike JMS, most JCA deployments do not provide XA based connection factories for client use. In other words you cannot simply get a reference to the connection factory in JNDI and get the XAResource.

                JMS is one thing, JCA is a different animal altogether.


                • 5. Re: JcaXAResourceRecovery

                  Your doing it all wrong. Read my previous comments.

                  What you need is a repository of XA TxConnectionManagers and MDB
                  activations (these are setup by the deployments).

                  When JBossTS asks you to recover, you iterate over this repository and retrieve
                  all the XAResources.

                  All you need is a mechanism to get a link to this repository from your JBossTS
                  plugin. If JBossTS supported proper IOC configuration this would trivial,
                  instead you going to have to do some work.

                  Don't make the same mistake and introduce property files for your configuration!

                  The only configuration required is the security like you said.
                  We discussed this nearly two years. It is trivially solved by allowing
                  a connection factory or datasource to have two extra parameters to override
                  the default user or when it doesn't have a default user.

                  e.g.

                  <local-tx-datasource>
                   ...
                   <recover-user>x</recovery-user>
                   <recover-password>y</recovery-password>
                  
                   <!-- OR -->
                  
                   <recovery-security-domain>Recovery</recovery-security-domain>
                  </local-tx-datasource>
                  


                  You might also need a flag to say recovery cannot use (share) a
                  normal pooled connection since I know at least in the past some XAResources had
                  problems with normal operations after recover() is invoked.

                  • 6. Re: JcaXAResourceRecovery

                     

                    "timfox" wrote:
                    Also, one thing I noticed when doing the XA recovery work for JBM is that the JMSProviderXAResourceRecovery instance that was done for JBossMQ is broken.


                    Please raise a bug report, or better yet, fix it! :-)

                    I hope your not planning to ask users to configure seperately JBoss Messaging
                    recovery (and especially no seperate property files)?

                    The aim is to try to make it zero configuration for recovery not asking them to configure
                    things in 5 different places.

                    I can understand supporting a seperate recovery plugin for standalone use
                    of JBoss Messaging but NOT in the appserver please, it should be
                    integrated via JCA!

                    The current JNDI provider based JMS recovery is half-way-house until
                    JCA does this properly.

                    • 7. Re: JcaXAResourceRecovery
                      weston.price

                       


                      Your doing it all wrong. Read my previous comments.


                      Lovely. I actually won a bet. I bet someone at JBoss that you wouldn't post a response without saying something like this. Of course, given your nature I probably should have given him odds.


                      When JBossTS asks you to recover, you iterate over this repository and retrieve
                      all the XAResources.


                      Ok, let's take a simple scenario:

                      JDBC based deployment using a security domain with a login config of CallerIdentityLoginModule. Just because the TxManager is deployed, doesn't mean the XAResource gets created. This comes off the underlying Connection which is only created when the pool is first used. So, what goes in the repository in this case? What do I iterate over during recovery?

                      How about a JDBC deployment that only support application-managed security? What if this is required information and can only be done via
                      getConnection(username,password)?



                      We discussed this nearly two years.


                      Well, unless you think my name is something other than Weston (which you actually seem completely incapable of remembering) we haven't. I have been here one year, and let me tell you I have loved every day!

                      The example you posted as a sample security configuration basically just offloads what would be in the external config file to the *-ds.xml, fine. I am not sure why you are listing a local-tx-datasource as these won't be supporting recovery, but no matter. So, I am assuming that your

                      <recovery-security-domain>Recovery</recovery-security-domain>
                      


                      is defined in login-config, so we have yet another piece of external information to 'kludge' this together it just happens to be in a 'comfortable' place that you are familiar with.







                      • 8. Re: JcaXAResourceRecovery
                        timfox

                         

                        "adrian@jboss.org" wrote:

                        Please raise a bug report, or better yet, fix it! :-)


                        Ok, I'll raise a report.


                        I hope your not planning to ask users to configure seperately JBoss Messaging
                        recovery (and especially no seperate property files)?

                        The aim is to try to make it zero configuration for recovery not asking them to configure
                        things in 5 different places.

                        I can understand supporting a seperate recovery plugin for standalone use
                        of JBoss Messaging but NOT in the appserver please, it should be
                        integrated via JCA!


                        For the app server we intend to use the JMSProvider based XAResourceRecovery, although it has the drawback of not being able to specify username and password as already mentioned on this thread.

                        The custom one, which uses it's own properties file is only currently used for the messaging bridge, which doesn't use JCA. Although I am coming around to the idea of deploying JCA with it too (the standalone bridge is really just a stripped down JBoss AS) then we can use the standard XAResource receovery.

                        We would like to have a "full" recovery solution for JBM before JBM 1.2 (at the end of the month) , which would need to include specifying a username and password. I don't know if the new JCA stuff is going to ready in time for that, so we may have no choice than to use our own properties file or maybe we can change the datasource to take recovery username/password params as you mention.




                        • 9. Re: JcaXAResourceRecovery

                           

                          "weston.price@jboss.com" wrote:

                          Your doing it all wrong. Read my previous comments.


                          Lovely. I actually won a bet. I bet someone at JBoss that you wouldn't post a response without saying something like this. Of course, given your nature I probably should have given him odds.


                          Sorry, but you deserved it. :-)

                          I already said you needed a repository and then you started talking about
                          configureing DS jndi names in the JBossTS config.
                          There's no way a user will remember to keep this in step! :-)

                          • 10. Re: JcaXAResourceRecovery

                             

                            "weston.price@jboss.com" wrote:

                            Ok, let's take a simple scenario:

                            JDBC based deployment using a security domain with a login config of CallerIdentityLoginModule. Just because the TxManager is deployed, doesn't mean the XAResource gets created. This comes off the underlying Connection which is only created when the pool is first used. So, what goes in the repository in this case? What do I iterate over during recovery?

                            How about a JDBC deployment that only support application-managed security? What if this is required information and can only be done via
                            getConnection(username,password)?



                            The cases we are talking about is where the security is already externally
                            configured. There is no default user name or password or it is the wrong one.

                            It is either application-managed-security or security domain based.

                            In the case where there is no default and one is required, you need to
                            configure it somewhere.

                            In the case where it is the wrong one (the normal runtime user doesn't have
                            authority to invoke recover()) you also need a seperate configuration.

                            These are the 1% use cases for completeness.
                            In 99% of uses cases the default user (either no user/password
                            or the one form the security domain) will suffice for recovery to create the connection.

                            • 11. Re: JcaXAResourceRecovery

                               

                              "weston.price@jboss.com" wrote:
                              I am not sure why you are listing a local-tx-datasource as these won't be supporting recovery, but no matter.


                              Brain fart on my part! :-)

                              • 12. Re: JcaXAResourceRecovery

                                 

                                "weston.price@jboss.com" wrote:

                                <recovery-security-domain>Recovery</recovery-security-domain>
                                


                                is defined in login-config, so we have yet another piece of external information to 'kludge' this together it just happens to be in a 'comfortable' place that you are familiar with.


                                No, it is the standard mechanism within the appserver for external security
                                configuration.

                                Personally, I think JCA should have a SubjectFactory integration point
                                which for the appserver uses JBoss-JAAS, but whatever you still need
                                to name the factory to use and the security-domain config is as good an
                                identifier as any.

                                e.g. In a standalone use case it could be a name for the SubjectFactory
                                in the microcontainer.
                                <property name="subjectFactory"><inject bean="Recovery"/></property>
                                


                                • 13. Re: JcaXAResourceRecovery
                                  bill.burke

                                   

                                  When I wrote the ResourceRecovery instance for the JMS bridge, it gets its config from a properties file


                                  We really need to stop people from doing this kind of stuff. Random property files are just not the way to go.

                                  • 14. Re: JcaXAResourceRecovery
                                    bill.burke

                                    We need to get into the JCA spec and define SPIs/APIs for recovery. What really sucks is that JBM is going to have to figure it out for every single app server out there if it wants to be usable in different environments. I guess people like ActiveMQ have already done the work though and we just need to steal the code...

                                    1 2 3 Previous Next