-
1. Re: Improvements to the transaction SPI
jaikiran May 18, 2013 12:38 AM (in response to mmusgrov)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:
com.arjuna.ats.arjuna.common.Uid
com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinateTransaction
com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinationManager
com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporter
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple
com.arjuna.ats.jbossatx.jta.TransactionManagerService
com.arjuna.ats.jta.recovery.XAResourceRecovery
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.
-
2. Re: Improvements to the transaction SPI
jesper.pedersen May 21, 2013 2:06 PM (in response to mmusgrov)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 ?
-
3. Re: Improvements to the transaction SPI
mmusgrov May 22, 2013 5:58 AM (in response to jesper.pedersen)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.
-
4. Re: Improvements to the transaction SPI
tomjenkinson May 22, 2013 6:13 AM (in response to mmusgrov)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
-
5. Re: Improvements to the transaction SPI
jesper.pedersen May 22, 2013 8:54 AM (in response to mmusgrov)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.
-
6. Re: Improvements to the transaction SPI
tomjenkinson May 31, 2013 7:04 AM (in response to jesper.pedersen)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
-
7. Re: Improvements to the transaction SPI
jesper.pedersen Oct 9, 2013 8:56 AM (in response to tomjenkinson)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.
-
8. Re: Improvements to the transaction SPI
mmusgrov Oct 9, 2013 10:06 AM (in response to jesper.pedersen)You can track our progress here: https://issues.jboss.org/browse/JBTM-1970
-
9. Re: Improvements to the transaction SPI
jesper.pedersen Mar 5, 2014 2:18 PM (in response to mmusgrov)I have added JBTM-2116 as a feature request, as the hashCode() for a JTS transaction currently isn't stable over its entire lifecycle
-
10. Re: Re: Improvements to the transaction SPI
jesper.pedersen Mar 12, 2014 10:57 AM (in response to jesper.pedersen)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)
txMap.remove(key);
-
11. Re: Improvements to the transaction SPI
tomjenkinson Aug 28, 2014 6:16 AM (in response to jesper.pedersen)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...
-
12. Re: Improvements to the transaction SPI
jesper.pedersen Sep 2, 2014 10:44 AM (in response to tomjenkinson)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.