4 Replies Latest reply on Oct 5, 2007 6:58 AM by Mark Little

    Integration of different tx manager with AS (and EAP) build+

    Jonathan Halliday Master

      By default the app server has a JTA implementation i.e. transactions don't span multiple JVMs. There is a limited ability to do remote (client side) demarcation of transaction boundaries, but it's transport dependent. Full, interoperable distributed transactions over IIOP are available by plugging in JBossTS JTS.

      Up to now the AS+JTS configuration been a second class citizen in terms of test coverage. However, it's going to be a supported part of the next enterprise platform, so I've been thinking about how to test the AS in that configuration. Some of the AS testsuite does not make sense, since there is no ORB in the default configuration. It should be possible to run those tests using the JTS code i.e. .jar files, configured for JTA mode operation (different property file). The tests for the all configuration are still valid, but there is no automatic way to build and test the server with the JTS rather than JTA.

      The general form of this question is: how to make the AS build and test process support a pluggable transaction manager. Pluggability is there at the API level, and getting there with respect to the testsuite code itself. However, the automated build+test process does not reflect it. It would be great to be able to inject an arbitrary implementation of the transaction-spi through build time configuration file and have it pulled in from a repository, have the app server built with it and have the tests run using it.

      That's probably going to need hooks in the build system though, since only the transaction system implementation knows e.g. what jar files need to go where, what config files need to go into each AS profile and so on. Right now that information is hardcoded into the AS build scripts and supports only JBossTS JTA. We can hardcod the JjBossTS JTS too, or look at ways to generalize the build process. That may apply to other pluggable components too e.g. pull in another WS stack or messaging bus at build time. Basically anything which is a pluggable component of the AS i.e. has an SPI defined for it.

      Any thoughts from the AS team?