Understood. Since breaking compatibility is a non-starter, what I had proposed was an enhancement to XAResource to add a new default method: /** * Ends the work performed [...rest of existing

I worked on the original XA prototype and wrote the draft XA specification that was submitted to X/Open. The goal of xa_start/xa_end is to associate a thread with a transaction/resource. There can be

It seems there was a delay on the first message being delivered hence this is somewhat of a duplicate. Let's discuss over on Mike's thread:

We had a suggestion on our Narayana forum (https://developer.jboss.org/thread/277738) regarding an enhancement that avoids the prepare phase if only one resource actually made any changes. The problem

We had a suggestion on our Narayana forum (https://developer.jboss.org/thread/277738) regarding an enhancement that avoids the prepare phase if only one resource actually made any changes. The problem

JTA 1.3 is completed so it can't go there. Release 1.3 is used to remove the three javax.transaction.xa.* classes that duplicate the classes owned by Java SE. Note that the javax.transaction.*

Just wondering if there has been any movement on this issue yet. Thanks! -- - DML

FYI – We are moving forward with the 1.3 JTA MR. Mark Little, representing the Eclipse Foundation, will be the co-lead on this effort. See more details below. -------- Forwarded Message --------

Since this proposal is beyond the scope of an MR, can you confirm that the MR will be withdrawn and set out the alternative mechanism here?

In order to support various frameworks, we have often needed the ability to register a callback onto a Transaction in order to allow these frameworks to track when a transaction is associated to

I see the link in the home of this group to the mailing list archives (http://download.oracle.com/javaee-archive/) but I can't find the archive for the JTA users mailing list. I tried to craft a URL

I'm not clear whether this is a new version (1.3) of the spec or a maintenance release of 1.2. It looks more like the former than a MR. A MR wouldn't be appropriate to the 1.2 spec as this is a Java

Hello, I’m pleased to announce that Stephen Felts will be the JTA spec lead (Maintenance Lead of JSR 907) going forward. Regards, Paul

Thanks Lance - the reference is much appreciated

Hi Tom, The javax.transaction.xa package is available in Java SE, so using the JTA 1.3 jar will work just fine on any Java SE release, without any additional jars needed. Best Lance Lance Andersen|

Hi Paul, Thanks for opening up this topic for discussion. What would you recommend for applications written in JDK8 that might wish to consume the eventual JTA 1.3 jar - from where is it expected that

Hello All and welcome to the new JTA group, We will be submitting an MR for JTA 1.3, shortly that will be limited in scope to: Removal of the javax.transaction.xa package This package will be