1 2 3 Previous Next 72 Replies Latest reply: May 14, 2010 11:40 AM by Jesper Pedersen RSS

JcaXAResourceRecovery

Weston M. Price Master

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 M. Price Master

    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
    Tim Fox Master

     

    "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
    Tim Fox Master

    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 M. Price Master

    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
    Adrian Brock Master

    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
    Adrian Brock Master

     

    "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 M. Price Master

     


    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
    Tim Fox Master

     

    "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
    Adrian Brock Master

     

    "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
    Adrian Brock Master

     

    "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
    Adrian Brock Master

     

    "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
    Adrian Brock Master

     

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

     

    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 Master

    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