Michael Musgrove wrote:
2) A number of projects are using internal arjuna APIs. I would like to provide the same functionality provided by those internal APIs in the transactions spi in order to avoid the need to depend on our private stuff. The relevant classes are:
EJB container heavily relies on those classes for remote transaction handling and transaction recovery. So when you have the new SPI ready, let me know, I can help with integrating and testing it.
Looks good Mike.
The com.arjuna classes should be hidden behind the new SPI too; providing the functionality that is needed from the classes used. So we need to dig more into that. Only the Narayana subsystem should import com.arjuna classes.
Jaikiran, what functionality do you depend on which currently only available through the specific classes ?
I've already made a first pass over wildfly and migrated all of the wildfly uses of arjuna placing them behind the new SPI and the tests are all pasing (the EJB susbsystem was the biggest user but the changes were straight forward). I am targetting integrating the new SPI into the next narayana release (which is imanent) after which I will raise a pull request against wildfly with the relevant changes to the various subsystems.
There is an outstanding question as to whether the SPI should contain narayana specific configuration options (jta/jts mode) as wildfly includes these com.arjuna.*EnvironmentBean classes.
i.e. is this a narayana-spi or is it a generic transaction manager spi
If it is the former, we could include the module in our narayana repo, otherwise it should remain in its own repo I would guess
Let me know, Mike since we need a Narayana plugin for IronJacamar using the new SPI.
The plugin implementation could be inside WildFly first, and we could then move it to IronJacamar for the next release. Stefano is currently integrating IronJacamar 1.1.0.Beta5 with WildFly, but there should be no new requirements on the SPI in that release.
We do intended to move the SPI from: https://svn.jboss.org/repos/jbossas/projects/integration/trunk/jboss-transaction-spi to: https://github.com/jbosstm/jboss-transaction-spi/ to enable ease of development (pull requests, consistent scm), please do shout up if this will be a problem
Looking at my notes there are two outstanding tasks for the transaction SPI.
First, org.jboss.tm.ConnectableLastResource shouldn't extend LastResource in order to make it a mix-in interface that can be used for XA resources too. Maybe rename it to ConnectableResource could be an idea.
Second, promotion of com.arjuna.ats.jta.resources.StartXAResource to the SPI. Maybe org.jboss.tm.FirstXAResource ?
It would be great we could get those sorted before WildFly 8/Final.
I have added JBTM-2116 as a feature request, as the hashCode() for a JTS transaction currently isn't stable over its entire lifecycle
JBTM-2216 is needed for cases where the Transaction instance is currently used as a key in a Map<Transaction, ?>, and the map is cleaned up in a Synchronization:afterCompletion() implementation. The map is static in order to coordinate across the JVM.
Example usage (constructor)
this.tx = tx; this.key = TxSPI.getIdentifier(tx); txMap.put(key, this);
Example usage (afterCompletion)
Assuming you have a reference to the Transaction (which I assume you must have) you should be able to always call get_uid() on it and get the same value:
We could create an SPI similar to http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html#getTransactionKey() which takes a Transaction as a reference and then performs code similar to:
As a workaround you could use reflection and invoke the get_uid method on the common get_uid method...
get_uid() isn't part of the JTA API, so that method can't be used, as IronJacamar supports any JTA 1.0+ transaction manager.
The IronJacamar TX/SPI already contains such a method - ironjacamar/TransactionIntegration.java at 1.2 · ironjacamar/ironjacamar · GitHub - it just needs an Narayana implementation. Calling get_uid() from the plugin could be an option - by type casting the passed in Transaction instance to all known Narayana based implementations - but having the method in the Narayana SPI would be a better solution.