[tomjenkinson]

Does it matter whether its a constructor or setter I wonder? Would be interested to know - if it helps somehow we should go with the one that is best for both use cases.

In terms of recovery, can we make NarayanaDataSourceBean retrieve an XAResource from the XADataSource, wrap it with a recoveryhelper and pass it into the recovery system: narayana/RecoveryManagerService.java at master · jbosstm/narayana · GitHub.

Something like (if it was the ctor, similar if it was a setter but would maybe need to remove the old one if present):

this.xaDataSource = xaDataSource;

XAResourceRecovery xaResourceRecovery = new XAResourceRecovery() {

  public XAResource getXAResource () throws SQLException {

    return xaDataSource.getXAResource();

  }

  // etc

};

RecoveryManager manager = RecoveryManager.manager();

XARecoveryModule xaRecoveryModule = // find module from manager;

xaRecoveryModule.addXAResourceRecoveryHelper(new XAResourceRecoveryHelperWrapper(xaResourceRecovery));

[gytis]

I'm thinking of adding an initialisation method (something like @PostConstruct), since doing that sort of things in a constructor would make it difficult to test and use. And initialisation methods can be registered in Spring too, so that shouldn't be a problem.

[tomjenkinson]

How about going down the setter route as Amos suggested? It seems logically connected when you set the XADS to set it up for recovery too.

[gytis]

Personally I think that it is a bit unnatural to make a setter call required all the time. They should be used to override things and not to initialise. While initialisation method always implies that it has to be called before using the object.

However, we can try both scenarios, since it's mainly just a different name for the same thing in this particular case.

[gytis]

Also, such wrapper should really be immutable IMO.

[tomjenkinson]

Maybe we should just go with the precedent set by the other implementations. This looks like a good opportunity to add it to the recovery manager but I am not sure of the opposite for raw Spring:

https://github.com/spring-projects/spring-boot/blob/877e6e034ce58cfa84a237579891a94e197c3b12/spring-boot/src/main/java/org/springframework/boot/jta/XAConnectionFactoryWrapper.java#L39

and:

https://github.com/spring-projects/spring-boot/blob/877e6e034ce58cfa84a237579891a94e197c3b12/spring-boot/src/main/java/org/springframework/boot/jta/XADataSourceWrapper.java

I imagine with raw spring we might need to add a new RecoveryManagerBean (which wraps our RecoveryManager) and can take a list of XAResource beans (from the datasources etc configured in the Spring).

[marklittle]

Summarise the proposal here?

[tomjenkinson]

I am suggesting that when spring calls the wrapConnectionFactory or wrapDataSource methods on our integration code it seems like a good opportunity (subject to Amos/Gytis investigation) for us to register that provided resource with the recovery manager as well. It does need investigation but I am assuming those methods are called once when the "container" (spring) is starting up and processing its configured environment. Alternatively we can do that with new beans that the user add to their environment.

[zhfeng]

Yeah, I agree with Tom that we need the RecoveryManagerBean just to wrapper our RecoveryManager. So in the spring context configuration, it should be

<bean id="recoveryManager" class="org.jboss.narayana.recovery.jta.RecoveryManagerBean"/>

and in term of the register the XAResource, I think we could reference the recoveryManger in the our XADataSourceBean and XAConnectionFacotryBean, just like

<bean id="ds1" class="org.jboss.narayana.jta.XADataSourceBean" depends-on="recoveryManager">
     <property name="recoveryManager" ref="recoveryManager"/>
     <properey name="datasource" ref="db"/>
</bean>

That means in the XADataSourceBean, we need to get the recoveryManager and register with XAResource as Tom suggested codes.

[gytis]

Hello,

I've finished Spring Boot quickstart, so feel free to try it out. It has commit, rollback, and recovery examples with JMS and JPA: quickstart/spring/narayana-spring-boot at master-JBTM-2634-spring-boot · gytis/quickstart · GitHub

In addition, since you can see how the Spring Boot integration works, I would like to ask you to take a look at the code and give me your thoughts Narayana JTA integration · gytis/spring-boot@a3bd5dc · GitHub. Once everybody is happy with it, I'll raise a pull request to Spring repository.

Unfortunately, since Spring Boot integration is not released, you'll need to build everything locally...

First of all, build current Narayana master. Then check out GitHub - gytis/spring-boot at spring-boot-starter-jta-narayana: Spring Boot and build it as usual without executing tests. After that you should be able to run the quickstart.

Thanks,

Gytis

[tomjenkinson]

I added a comment on the spring-boot diff itself (a sleep). I am wondering, is there a tooling system we are meant to integrate with as well? For example, what is the proposal to list and resolve heuristic transactions?

[gytis]

This sounds more like a follow up work once this one is merged into Spring Boot, don't you think? Because I'm not sure how long will it take to get the current code there.

[tomjenkinson]

It depends on their requirements rather than ours - do the other transaction managers expose tooling?

[mmusgrov]

We provided tooling for transaction logs via JMX. The details are in the INSTALL notes for the standalone product (narayana/narayana-full at master · jbosstm/narayana · GitHub)

We also have a JIRA for a comandlne base tool similar to the WildFly console ([JBTM-2646] Include a quickstart showing a command line equivalent of the wildfly transaction console - JBoss Issue Trac…)

which you can vote up if required.

[haskovec]

I was looking at the Github repository you posted that was the fork of the Spring Boot Project. However when I clone your repository I don't see a spring-boot-starter-jta-narayana directory which I would expect to see by the atomikos and bitronix integrations. Has the spring team responded as to whether they are willing to include the integration into Spring boot and if so do you guys have a timeframe on when that might happen?