1. jta-spec@javaee.groups.io
   Date   
Re: Suggestion for a 2PC optimisation

David Lloyd
 

On Fri, Apr 27, 2018 at 1:25 PM, Stephen Felts <stephen.felts@oracle.com> wrote:
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 many such associations for a global
transaction/resource on different threads within a process, on different
processes, and different machines. It's not just a simple start/end, we are
done, and we have the answer based on a single return value.
Understood.

We extended that goal only for the rollback case, where a rollback from any
association on the transaction indcates that the entire transaction will be
rolled back. We don't need to worry about the return values from other
associations with the transaction. This optimization allows for the TM to
short-cut even starting subsequent associations for the same transaction,
propagating communications associated with the transaction, etc.

Extending the goal to provide read-only information is not so straight
forward. The fact that one association returns read-only does not imply
that we can take any action other than keeping track of that piece of
information because there could be many other such associations for the
transaction/resource that are not read-only. So the read-only information
would need to be tracked, ignored if any related association returns OK,
combined across all associations everywhere, and can only be acted on in the
first phase of commit when we know there will be no further associations
allowed. If all associations for the transaction/reesource are read-only,
then 1PC can be used. I don't believe that we considered returning
read-only from xa_end.

Adding this feature now would be complicated because it impacts both the RM
and the TM. Most if not all changes to the JTA specification impact only
the TM. Changing the RM can cause a behavior in the unupdated TM that is
not expected. I can see the code that was written 30 years ago with a
switch on the return value from xa_end and it doesn't handle XA_RDONLY
(unknown return values are treated as an error that causes the transaction
to fail).
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 spec language...].
* The return value of this method is only a hint; the transaction
manager is free to ignore it.
* [...]
* @return XA_RDONLY if the resource instance did no work during its
association; XA_OK if work was done or it cannot be determined.
*/
default int endWithResult(Xid xid, int flags) {
end(xid, flags);
return XA_OK;
}

The possible return values are XA_RDONLY and XA_OK. If the TM does
not support this method, it does not call it (as it is only a hint).
If the RM does not support it, it does not override it. Compatibility
(forward and backward) is in this way guaranteed, since the method
does not mandate new behavior on either part.

You are correct that a TM supporting this enhancement would have to
record the value returned for each XAResource instance, and it can
only consider the RM to be optimizable if all of its XAResource
instances returned XA_RDONLY. But as the TM would not be required to
do so, I don't think that it constitutes undue complication to the
specification, even without consideration for the benefit of this
enhancement. Once all pre-commit synchronizations are complete, the
transaction can be prepared as normal, with the only change of
ordering XA_RDONLY resources before XA_OK resources. This way, no new
error states are created, since even an inconsistent return between
the endWithResult call(s) and the prepare call would not cause
incorrect operation (the return is only a hint after all).

--
- DML

On Fri, Apr 27, 2018 at 1:25 PM, Stephen Felts <stephen.felts@oracle.com> wrote:
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 many such associations for a global
transaction/resource on different threads within a process, on different
processes, and different machines. It's not just a simple start/end, we are
done, and we have the answer based on a single return value.

We extended that goal only for the rollback case, where a rollback from any
association on the transaction indcates that the entire transaction will be
rolled back. We don't need to worry about the return values from other
associations with the transaction. This optimization allows for the TM to
short-cut even starting subsequent associations for the same transaction,
propagating communications associated with the transaction, etc.

Extending the goal to provide read-only information is not so straight
forward. The fact that one association returns read-only does not imply
that we can take any action other than keeping track of that piece of
information because there could be many other such associations for the
transaction/resource that are not read-only. So the read-only information
would need to be tracked, ignored if any related association returns OK,
combined across all associations everywhere, and can only be acted on in the
first phase of commit when we know there will be no further associations
allowed. If all associations for the transaction/reesource are read-only,
then 1PC can be used. I don't believe that we considered returning
read-only from xa_end.

Adding this feature now would be complicated because it impacts both the RM
and the TM. Most if not all changes to the JTA specification impact only
the TM. Changing the RM can cause a behavior in the unupdated TM that is
not expected. I can see the code that was written 30 years ago with a
switch on the return value from xa_end and it doesn't handle XA_RDONLY
(unknown return values are treated as an error that causes the transaction
to fail).



--
- DML
Re: Suggestion for a 2PC optimisation

Stephen Felts
 

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 many such associations for a global transaction/resource on different threads within a process, on different processes, and different machines.  It's not just a simple start/end, we are done, and we have the answer based on a single return value.

We extended that goal only for the rollback case, where a rollback from any association on the transaction indcates that the entire transaction will be rolled back.   We don't need to worry about the return values from other associations with the transaction.  This optimization allows for the TM to short-cut even starting subsequent associations for the same transaction, propagating communications associated with the transaction, etc.

Extending the goal to provide read-only information is not so straight forward.  The fact that one association returns read-only does not imply that we can take any action other than keeping track of that piece of information because there could be many other such associations for the transaction/resource that are not read-only.  So the read-only information would need to be tracked, ignored if any related association returns OK, combined across all associations everywhere, and can only be acted on in the first phase of commit when we know there will be no further associations allowed. If all associations for the transaction/reesource are read-only, then 1PC can be used.  I don't believe that we considered returning read-only from xa_end.

Adding this feature now would be complicated because it impacts both the RM and the TM.  Most if not all changes to the JTA specification impact only the TM.   Changing the RM can cause a behavior in the unupdated TM that is not expected.  I can see the code that was written 30 years ago with a switch on the return value from xa_end and it doesn't handle XA_RDONLY (unknown return values are treated as an error that causes the transaction to fail).
Re: Possibility of a 2PC optimisation?

Tom Jenkinson
 

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: https://javaee.groups.io/g/jta-spec/topic/suggestion_for_a_2pc/18102512?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,18102512
Suggestion for a 2PC optimisation

Michael Musgrove
 

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 is that during prepare processing - while we may know that in a given specific case only one resource will return XA_OK from prepare (the rest returning XA_RDONLY), it's only a matter of chance as to whether that particular resource will end up last in the list (and thus be eligible for 1PC optimization). 
 
The suggestion is to indicate, ahead of time, that the transaction branch did not do any work.
 
The end call would have been an ideal opportunity to report this information. I would like to ask if, during the writing of the XA spec, why XA_RDONLY was not considered to be a valid return value from the xa_end() call.
Possibility of a 2PC optimisation?

Tom Jenkinson
 

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 is that during prepare processing - while we may know that in a given specific case only one resource will return XA_OK from prepare (the rest returning XA_RDONLY), it's only a matter of chance as to whether that particular resource will end up last in the list (and thus be eligible for 1PC optimization). 
 
The suggestion is to indicate, ahead of time, that the transaction branch did not do any work.
 
The end call would have been an ideal opportunity to report this information.

We would like to ask if, during the writing of the XA spec, anyone is aware of why XA_RDONLY was not considered to be a valid return value from the xa_end() call in order to support this possibility?
Re: Proposed enhancement to the JTA API

Stephen Felts
 
Edited

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.* classes have been removed from Java SE 11 so there is no longer an overlap between Java SE and Java EE for the transaction API classes. See https://jcp.org/aboutJava/communityprocess/mrel/jsr907/index3.html for downloads.

Also note that the Java Transaction API project has been moved to the Eclipse Enterprise for Java (EE4J) project so the processing going forward will need to change.

I realize this isn't getting to the heart of your request but just clarifying what is happening with respect to releases of the API jar file.
Re: Proposed enhancement to the JTA API

David Lloyd
 

Just wondering if there has been any movement on this issue yet.

Thanks!

On Thu, Dec 7, 2017 at 8:06 AM, David Lloyd <david.lloyd@redhat.com> wrote:
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 or
dissociated from a thread. We accomplish this today using internal
APIs. After some internal discussions it was decided that this should
be brought to the spec group for discussion.

I would like to request that the JTA API be enhanced to provide a
simple thread association callback, like this:

/**
* A transaction-to-thread association listener.
*/
public interface AssociationListener {
/**
* Inform the listener that a transaction's thread association has changed.
*
* @param transaction the transaction whose association has
changed (not {@code null})
* @param associated {@code true} if the association was created,
or {@code false}
* if the association was removed
*/
void associationChanged(Transaction transaction, boolean associated);
}

The association callback is called with a value of 'true' as the last
action of a transaction resume or begin, and with a value of 'false'
as the first action of a transaction suspend, or of a commit or
rollback that happens by way of the TransactionManager interface.

Here are a few ideas for the registration portion of the API.

Option 1: Enhance javax.transaction.Transaction

public interface Transaction {
// [...]

/**
* Register a transaction association listener.
*
* @param listener the listener to register (must not be {@code null})
*/
void registerAssociationListener(AssociationListener listener);
}

Option 2/3: Enhance
javax.transaction.TransactionSynchronizationRegistry or
javax.transaction.TransactionManager

For example:

public interface TransactionSynchronizationRegistry {
// [...]

/**
* Register a transaction association listener on to a transaction.
*
* @param transaction the transaction to register to (must not be
{@code null})
* @param listener the listener to register (must not be {@code null})
*/
void registerAssociationListener(Transaction transaction,
AssociationListener listener);
}

Any thoughts on the feasibility of this enhancement for JTA 1.3?
--
- DML
--
- DML
Some guidelines for Maintenance Releases (MRs) of Java EE 8 Specifications

Stephen Felts
 

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 --------

Subject:

Some guidelines for Maintenance Releases (MRs) of Java EE 8 Specifications

Date:

Sun, 7 Jan 2018 17:25:13 -0500

From:

will.lyons@...

Organization:

Oracle Corporation

To:

ee4j-community@...

 

Hello -

Oracle continues to work with members of the Java EE community to contribute GlassFish and Java EE 8 technologies to the Eclipse Enterprise for Java (EE4J) project at the Eclipse Foundation.   We expect these technologies to evolve within EE4J, and we do not expect there will be a “Java EE 9” or a GlassFish Reference Implementation for it.  However, as stated previously in the EE4J FAQ, Oracle may deliver maintenance releases of GlassFish 5.0 and related Java EE 8 JSRs.

The first example of a Java EE 8 JSR Maintenance Release (MR) has surfaced.   Future releases of Java SE will require clearer demarcation of those aspects of the Java Transaction API specification (JSR 907) that are a) implemented in Java SE and b) implemented in Java EE implementations.   An MR of JSR 907 has been opened to provide this clarification and demarcation, and is available at:
https://jcp.org/en/jsr/detail?id=907

No functional changes to the JTA specification are planned as part of this MR.  Oracle has proposed to use the JCP process to review this MR, while the Eclipse Enterprise for Java (EE4J) specification process is being defined.   The use of the JCP process for this Java EE specification is only intended for this maintenance purpose during this interim period when the EE4J process is being defined.   The Eclipse Foundation will act as co-lead of the JTA specification with Oracle, and Mark Little of Red Hat will serve in the role of co-spec lead, and Oracle, Eclipse, and Red Hat have jointly agreed to represent the interests of EE4J in leading this specification.   

This MR raises a general question of when MRs for current Java EE 8 specifications is appropriate.  We thought it would be useful to establish and communicate guidelines for using the MR process for Java EE 8 specifications.  

Oracle recommends and supports the use of EE4J-driven processes for functional enhancements to Java EE 8 specifications, and does not recommend or support use the JCP process for any future Java EE 8 functional enhancements. However, from time to time there may be valid reasons for providing MRs of Java EE 8 specifications.

Appropriate reasons for introducing MRs to current Java EE 8 Specifications are the following:
i)     Fixing potential errata in specifications, in order to clarify or correct the specifications to align with the original intent of the specification.
ii)    Addressing potential security vulnerabilities that may be associated with current specifications.
iii)   Enabling clearer demarcation of those aspects of Java EE specifications that are implemented in Java SE and those that are implemented in Java EE, as required to enable evolution of the Java SE platform in a timely manner.   The technologies currently shared by EE and SE, and the plan to achieve clear demarcation, are publicly covered in http://openjdk.java.net/jeps/320.  Any material changes to this JEP will be shared directly with the EE4J PMC.  

As Java EE Spec lead, Oracle will discourage the use of the JCP process for MRs to Java EE 8 Specifications for any other reason than those given above.  The EE4J process should be used.   If some additional reason for a Java EE 8 MR is identified, Oracle will encourage that the spec lead or expert group proposing the MR review the reason for the MR with the EE4J Project Management Committee (PMC).  The EE4J PMC will determine if there is a valid reason for the MR and will update the list above as appropriate.

We hope this note provides context for the JTA MR above and review of other potential MRs going forward.  Thanks very much.

Will
Re: Welcome and changes to JTA/XA package changes...

jon.hawkes@...
 

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?
 
Proposed enhancement to the JTA API

David Lloyd
 

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 or
dissociated from a thread. We accomplish this today using internal
APIs. After some internal discussions it was decided that this should
be brought to the spec group for discussion.

I would like to request that the JTA API be enhanced to provide a
simple thread association callback, like this:

/**
* A transaction-to-thread association listener.
*/
public interface AssociationListener {
/**
* Inform the listener that a transaction's thread association has changed.
*
* @param transaction the transaction whose association has
changed (not {@code null})
* @param associated {@code true} if the association was created,
or {@code false}
* if the association was removed
*/
void associationChanged(Transaction transaction, boolean associated);
}

The association callback is called with a value of 'true' as the last
action of a transaction resume or begin, and with a value of 'false'
as the first action of a transaction suspend, or of a commit or
rollback that happens by way of the TransactionManager interface.

Here are a few ideas for the registration portion of the API.

Option 1: Enhance javax.transaction.Transaction

public interface Transaction {
// [...]

/**
* Register a transaction association listener.
*
* @param listener the listener to register (must not be {@code null})
*/
void registerAssociationListener(AssociationListener listener);
}

Option 2/3: Enhance
javax.transaction.TransactionSynchronizationRegistry or
javax.transaction.TransactionManager

For example:

public interface TransactionSynchronizationRegistry {
// [...]

/**
* Register a transaction association listener on to a transaction.
*
* @param transaction the transaction to register to (must not be
{@code null})
* @param listener the listener to register (must not be {@code null})
*/
void registerAssociationListener(Transaction transaction,
AssociationListener listener);
}

Any thoughts on the feasibility of this enhancement for JTA 1.3?
--
- DML
Archive for old mailing list?

Tom Jenkinson
 

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 that I thought could work (http://download.oracle.com/javaee-archive/jta-spec.java.net/users/) but that 404s.

Is the archive uploaded yet?
Re: Welcome and changes to JTA/XA package changes...

Ian Robinson
 

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 EE 7/8 spec which needs to work with JDK 8, so the package can't be removed from JTA 1.2.
These proposed changes for a new JTA 1.3 spec should surely be considered under a new JSR, not a MR.
new spec lead

Paul Parkinson
 

Hello,

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

Regards,
Paul
Re: Welcome and changes to JTA/XA package changes...

Tom Jenkinson
 

Thanks Lance - the reference is much appreciated
Re: Welcome and changes to JTA/XA package changes...

Lance Andersen
 

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
On Nov 14, 2017, at 7:57 AM, Tom Jenkinson <thjenkin@...> wrote:

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 these applications source interface files such as javax.transaction.xa.XAResource? Perhaps the recommendation might be that implementers provide a small additional jar with the javax.transaction.xa classes in it for JDK8 usage?

Best regards,
Tom


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen@...
Re: Welcome and changes to JTA/XA package changes...

Tom Jenkinson
 

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 these applications source interface files such as javax.transaction.xa.XAResource? Perhaps the recommendation might be that implementers provide a small additional jar with the javax.transaction.xa classes in it for JDK8 usage?

Best regards,
Tom
Welcome and changes to JTA/XA package changes...

Paul Parkinson
 

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 subsumed into the Java Platform JSR and will no longer be part of the JTA specification
  •  Specify that the  module name for JTA is java.transaction

The JTA 1.3 jar will include the MANIFEST attribute Automatic-Module-Name  specifying ‘java.transaction’ as its module name

Why do we want to do this?

  • Java SE has provided a subset of JTA since Java SE 1.3 
  • javax.transaction.xa  supports XA transactions in JDBC.and is co-located with JDBC in the java.sql module in Java SE 9. Because the java.sql module is not upgradeable, it is not possible for a standalone version of JTA to override the Java SE version of the XA package, but this is generally acceptable to applications because the XA package has been stable for many years and the Java SE version is identical to the Java EE version. 
    • JEP 261[1] indicates that:
      • If a package is defined in both a named module and on the class path then the package on the class path will be ignored. The class path can, therefore, no longer be used to augment packages that are built into the environment. The javax.transaction package, e.g., is defined by the java.transaction module, so the class path will not be searched for types in that package. This restriction is important to avoid splitting packages across class loaders and across modules. At compile time and run time the upgrade module path can be used to upgrade modules that are built-in into the environment. The --patch-module option can be used for other ad-hoc patching.
  • By removing javax.transaction.xa:
    • Eliminates the split package  issue[2] as the java.sql module now provides javax.transaction.xa
      • Alex Buckley's "Under the Hood" session from JavaOne 2016 [3] is a great resource for understanding the split package issue. 
    • Allows JTA to be specified on the module path
      • The java.transaction  module in Java SE 9  is an upgradable module, and used by modules such as java.corba
      • Provides for the use of the full version of JTA, which includes additional  types that are not in Java SE, that may be required by Java EE applications
  • The Automatic-Module-Name MANIFEST attribute allows for JTA  to have a stable module name (which has already been defined by Java SE following the naming convention specified in JEP 200[5])
    • Once other dependencies, such as CDI,  have stable module names, then JTA may become an explicit module
  • Will help avoid issues with developers[4] requiring JTA and migrating to Java SE 9
  • Will be consistent across implementations
    • example: Maven artifact: org.jboss.spec.javax.transaction: jboss-transaction-api_1.2_spec 

    A standalone version of JTA is available as the Maven artifact javax.transaction : javax.transaction-api. As of November 2017, this JAR file represents JTA 1.2, which consists of both the XA package, javax.transaction.xa,  and the CORBA interop package, javax.transaction. The JAR files for JTA 1.2 and the upcoming JTA 1.3 may be deployed as follows:

    • The JAR file for JTA 1.2 may be deployed on the classpath. (The XA package in the JAR file is ignored in favor of the XA package in the java.sql module. The CORBA interop package, javax.transaction,  in the JAR file is used in preference to the package in the java.transaction module, which is not resolved by default on JDK 9. Note that if --add-modules java.se.ee or --add-modules java.transaction is used on JDK 9, then the CORBA interop package in the JAR file will be ignored in favor of the package in the java.transaction module.)
    • The JAR file for JTA 1.2 may not be deployed on the modulepath. (It would be treated as an automatic module that contains the XA package, but this package would conflict with the XA package in the java.sql module.)
    • The JAR file for JTA 1.3 may be deployed on the classpath. (The CORBA interop package in the JAR file is used in preference to the package in the java.transaction module, which is not resolved by default in JDK 9.)
    • The JAR file for JTA 1.3 may be deployed on the modulepath and used as an automatic module called java.transaction.


    Regards,
    Paul
    1 - 17 of 17