1 2 3 4 5 Previous Next 72 Replies Latest reply: May 14, 2010 11:40 AM by Jesper Pedersen Go to original post RSS
  • 30. Re: JcaXAResourceRecovery
    Scott Stark Master

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

    Were any JIRA issues created from this thread?

    I've just closed the issues that were raised for the now obsolete old TM
    http://jira.jboss.com/jira/browse/JBAS-1402

  • 32. Re: JcaXAResourceRecovery
    Jonathan Halliday Master

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

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

    NOTE: I allow mutlple XAResources because of the ResourceAdapter
    http://java.sun.com/j2ee/1.4/docs/api/javax/resource/spi/ResourceAdapter.html
    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">
     <parameter><this/></parameter>
     </install>
     <uninstall bean="TMService" method="removeXAResourceRecovery">
     <parameter><this/></parameter>
     </uninstall>
    </bean>
    


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

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


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

    LEGACY

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

    <mbean ...>
     <attribute name="TMService><inject bean="TMService"/></attribute>
    
    public void startService() throws Exception
    {
     getTMService().addXAResourceRecovery(this);
    }
    public void stopService() throws Exception
    {
     getTMService().removeXAResourceRecovery(this);
    }
    


    IMPLEMENTATION AND SECURITY

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

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

     

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

    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

    close();
    

    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
    Jonathan Halliday Master

    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.

    http://jira.jboss.com/jira/browse/JBAS-5541

  • 38. Re: JcaXAResourceRecovery
    Jesper Pedersen Master

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

     

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

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

  • 41. Re: JcaXAResourceRecovery
    Jonathan Halliday Master

    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
    Jesper Pedersen Master

    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
    Jonathan Halliday Master

    > 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
    Jesper Pedersen Master

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