Hi Paul,
I've put this BOF on my schedule as well... Thanks!
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Kevin Sutter
STSM, Java EE and Java Persistence API (JPA) architect
mail: sutter_at_us.ibm.com, Kevin Sutter/Rochester/IBM
http://webspherepersistence.blogspot.com/
phone: tl-553-3620 (office), 507-253-3620 (office)
http://openjpa.apache.org/
From: Reza Rahman <Reza.Rahman_at_oracle.com>
To: users_at_jta-spec.java.net
Date: 08/12/2014 10:16 AM
Subject: [jta-spec users] Re: JTA 1.3
I also plan to be there.
On 8/11/2014 8:02 PM, Paul Parkinson wrote:
Great! It’s BOF3080 Monday, Sep 29 9:00 PM - 9:45 PM Parc 55 - Mission
(139)
Thanks,
Paul
On Jul 29, 2014, at 6:28 AM, Mark Little <mlittle_at_redhat.com> wrote:
When’s the BOF? I’ll be there.
Mark.
On 28 Jul 2014, at 20:48, Paul Parkinson <paul.parkinson_at_oracle.com>
wrote:
Hello All,
I just wanted to ping everyone on this to see what we would like to get
into the next JTA MR?
As stated in my last email, we currently only have "JTA_SPEC-4/ordered
commit" and "JTA_SPEC-9/setRollbackOnly(Exception) API addition” planned.
We still need to fully define these but I’d also like to know what
everyone might see as the next in line priority-wise?
I’ll also take this chance to mention/plug a JTA BoF I’ll be giving at
JavaOne this September/October.
Regards,
Paul
On Feb 12, 2014, at 2:24 PM, Paul Parkinson <paul.parkinson_at_oracle.com>
wrote:
Hi Jonathan,
Apologies for the long delay and thanks as always for your thoughts. We
are definitely trying to figure out the schedule and other activities re
Java EE8 though I don't have any dates to give at the moment.
Definitely some great ideas here and worth JIRA entries so maybe we can
work on that together and also take a stab at prioritizing?
I have such a list in the previous email below and so I'm not sure where
you think some of the times you mention would fall relative to that. Eg,
I think the ordered-commit feature is still the priority for JTA 1.3.
Along these lines I would like to ask what everyone feels are the must
have items? Currently we only have "JTA_SPEC-4/ordered commit" and
"JTA_SPEC-9/setRollbackOnly(Exception) API addition".
I have some comments inline...
Thanks,
Paul
On Jan 23, 2014, at 12:57 PM, Jonathan Halliday wrote:
Been quiet around here for a while... Paul, any schedule in mind for 1.3?
One more RFE idea before I forget it again. It's sort of related to
resource ordering I guess, though not really:
Transactions in Java EE often repeatedly contain the same set of RMs, such
as when an EJB method with REQUIRES_NEW hits the same database every time
it is executed. Although this information could in many cases be provided
explicitly at deployment time, or perhaps calculated by static code
analysis or runtime JIT like executing tracing, there is currently no way
to utilise it.
XA optimises only after the fact (1PC, read-only), which limits its
opportunities. It's relatively costly to use XA unnecessarily (e.g.
additional network trips for start/end) when RM local tx would do. It's
also painful to users to deploy xa and non-xa datasources for the same RM
and have to know which one to use if they want to hand optimise the single
resource or multiple read-only resource transactions.
I don't propose updating XA, but a big chunk of enterprise db access is
now Java based (last time I looked there are more XA aware JDBC drivers
than C ones for some RMs) so perhaps there is a chance to gain some
benefit here by tweaking JTA and perhaps JCA/JDBC?
Certainly I agree and indeed think it will involve coordinated changes
across these specs and maybe JMS as well.
Optionally providing information to begin(), such as expected resource
count or read/write characteristics, would be a good first step. For
example the container could enlist a local-tx mode db connection rather
than an XA one if we knew we'd be doing a 1PC in the end anyhow.
I do agree with the API additions for the begin call. Eg, in WebLogic we
have begin extensions for transaction name and timeout and there is the
ability to set properties on the transaction for other aspects so I can
perhaps see having the ability/API to pass properties (the classic
catch-all ;) ) to begin as well.
I think your next point on less predictable cases is maybe more compelling
as apps are generally very dynamic and if the app truly isn't going to
change then, e.g. in the 1pc case mentioned, I would think it should just
be configured to use a non-XA/local connection but of course we can
discuss more and I hear your point re defining multiple resource types.
For less predictable cases ideally I'd also like a way to take a regular
local tx resource (fake 'last resource' XAResource) and 'promote' it to
real XA even if it has uncommitted changes, though that is going to need
JCA and probably JDBC changes for the API and implementation would clearly
have to be optional for RMs and their drivers.
Right. Just to be complete, there are two approaches here as I see it:
- The current approach, which is in the Java EE spec re local transaction
optimization, is where the first resource used in a tx is a local conn/tx
and in the event that a second resource is used that second resources is
XA and a last resource commit protocol is employed.
- The nicer approach that you are referring to which is a JDBC (and JMS
and JCA to be complete really) API to lazily promote a local tx connection
(that potential has work conducted on it already) to an XA connection.
This too has been around for a while but never specified.
Once upon a time the disk I/O for logging dominated the network costs and
this wouldn't have brought much benefit. These days with SSDs already here
and persistent RAM just around the corner, but the speed of light
remaining stubbornly constant, I think there is more scope to realise
performance benefits by providing optional enhancements to the traditional
XA pattern.
Agree. I've had a significant/liong list of these for a while now
actually ;) .
Anyone else care to weigh in?
Jonathan.
On 09/03/2013 07:20 PM, Paul Parkinson wrote:
Thanks Jonathan.
Weighing in your comments I'd say the priority and status/action(s) by
JIRA are roughly:
JTA_SPEC-4 "2pc resource ordering" Actions: Should be included in 1.3.
Discuss scope and details (start email thread)
JTA_SPEC-9 "setRollbackOnly (Exception nestedException) and other
convenience APIs" Actions: Should be included in 1.3. Discuss scope and
details (start email thread)
JTA_SPEC-6 "clarify synchronization restrictions" Actions: vote to include
in 1.3, defer, or decline.
JTA_SPEC-11 "clarify synchronization ordering for dist tx" Actions: vote
to include in 1.3, defer, or decline.
JTA_SPEC-2 "portable restore of XAResources" Actions: defer
JTA_SPEC-8 "XAResource timeout". Actions: vote to include in 1.3, defer,
or decline.
Replies inline...
Thanks,
Paul
On Aug 27, 2013, at 10:36 AM, Jonathan Halliday wrote:
awww, no shiny 2.0 yet? Oh well :-)
Sounds like it's in large part a judgement call/convention really but
needs to be cohesive as far as marketing (e.g. major feature release or
not), etc.
What's the target jdk version for 1.3? specifically, can we rely on having
interface extension (defender methods) or are we still stuck with kludgy
TSR style class additions here?
If it makes it into EE8 (which would be the hope though we can't be sure
at this point) then SE8 would be the target (it's seems maybe you meant
"default" and not "defender").
-4 is certainly the priority. At the risk of scope creep I'd welcome some
discussion of more general approaches to communicating resource semantics,
such that we can do variations on Last Resource Commit Optimization /
Logging Last Resource, parallel prepare, etc
Starting separate email thread on this.
-8 I'm actually a little wary of. There are nasty race conditions that
happen if the TM and RM are concurrently terminating a transaction,
causing warnings in the log files etc. For which reason, we give a little
offset to the timeout we pass to the RM. I'm all in favour of making
clear the TM should set a timeout on the resource by default, but we
should leave a little room for manoeuvre with regard to the actual value.
It's also possible that the tx timeout is mostly expired at the time of
resource enlistment, in which case the value passed to the resource could
more conservatively be based on the remaining time, not the time
originally set. Speaking of which, how do we feel about
getTransactionTimeout()/getTransactionTimeoutRemaining() ?
Understood and yes I'd been thinking about getTransactionTimeoutRemaining
for a while now myself.
-9 seems like a nice usability improvement with no downside. On the topic
of exceptions I'd also like XAExceptions to require a value ctor to ensure
they have a valid code, but since they currently have a no-arg ctor that
probably comes under the heading of non-compatible change :-( Deprecation
maybe?
Yes, I agree and I think deprecation is the best route but of course am
open to others thoughts.
-2 is a longstanding pain point for implementers, but largely invisible to
end users. I'm therefore reluctantly forced to admit it's probably lower
priority than some of the other stuff. How long do we have for the 1.3
cycle anyhow?
Timelines for JTA 1.3 and correlation with EE8 are unknown at this point.
I'll keep updating as things develop.
Jonathan.
On 08/23/2013 11:58 PM, Paul Parkinson wrote:
Hello All,
Let's crack on shall we? ;-)
<
https://java.net/jira/browse/JTA_SPEC-4>Below are the 6 current open
items.
There was definitely consensus to have JTA_SPEC-4 "support explicit
ordering of commits […]" make it into 1.3 and I will send/continue a
separate email thread for discussion on that.
What does everyone think as far as priority/desire for the others? Any
to add?
Regards,
Paul
<
https://java.net/jira/browse/JTA_SPEC-4>
*T* *Key* *Summary* *Assignee* *Reporter* *Pr* *Status* *Res* *Created*
*Updated* *Due* [Ascending order - Click to sort in descending order] **
New Feature <
https://java.net/jira/browse/JTA_SPEC-4> JTA_SPEC-4
<
https://java.net/jira/browse/JTA_SPEC-4> support explicit ordering of
commits for XAResources enlisted in a transaction
<
https://java.net/jira/browse/JTA_SPEC-4> Unassigned paul_parkinson
<
https://java.net/jira/secure/ViewProfile.jspa?name=paul_parkinson>
Major Open Open UNRESOLVED 20/Aug/12 04/Nov/12
/Actions/
<
https://java.net/jira/rest/api/1.0/issues/116604/ActionsAndOperations>
New Feature <
https://java.net/jira/browse/JTA_SPEC-6> JTA_SPEC-6
<
https://java.net/jira/browse/JTA_SPEC-6> Clarify transaction
interactions/restrictions in TX Synchronization callbacks
<
https://java.net/jira/browse/JTA_SPEC-6> Unassigned frenchc
<
https://java.net/jira/secure/ViewProfile.jspa?name=frenchc> Major
Open Open UNRESOLVED 30/Aug/12 30/Aug/12
/Actions/
<
https://java.net/jira/rest/api/1.0/issues/116819/ActionsAndOperations>
Improvement <
https://java.net/jira/browse/JTA_SPEC-8> JTA_SPEC-8
<
https://java.net/jira/browse/JTA_SPEC-8> specify XAResource(s)
transaction timeout value be set to the value of the encompassing JTA
transaction's timeout value by default for portability.
<
https://java.net/jira/browse/JTA_SPEC-8> Unassigned paul_parkinson
<
https://java.net/jira/secure/ViewProfile.jspa?name=paul_parkinson>
Major Open Open UNRESOLVED 11/Oct/12 11/Oct/12
/Actions/
<
https://java.net/jira/rest/api/1.0/issues/117855/ActionsAndOperations>
New Feature <
https://java.net/jira/browse/JTA_SPEC-9> JTA_SPEC-9
<
https://java.net/jira/browse/JTA_SPEC-9> new api for setRollbackOnly so
that it can take a nested exception
<
https://java.net/jira/browse/JTA_SPEC-9> Unassigned paul_parkinson
<
https://java.net/jira/secure/ViewProfile.jspa?name=paul_parkinson>
Major Open Open UNRESOLVED 10/Dec/12 10/Dec/12
/Actions/
<
https://java.net/jira/rest/api/1.0/issues/119882/ActionsAndOperations>
Improvement <
https://java.net/jira/browse/JTA_SPEC-11> JTA_SPEC-11
<
https://java.net/jira/browse/JTA_SPEC-11> elaborate on ordering
semantics for Synchronization calls in a distributed transaction
<
https://java.net/jira/browse/JTA_SPEC-11> Unassigned paul_parkinson
<
https://java.net/jira/secure/ViewProfile.jspa?name=paul_parkinson>
Major Open Open UNRESOLVED 23/Aug/13 23/Aug/13
/Actions/
<
https://java.net/jira/rest/api/1.0/issues/127818/ActionsAndOperations>
New Feature <
https://java.net/jira/browse/JTA_SPEC-2> JTA_SPEC-2
<
https://java.net/jira/browse/JTA_SPEC-2> portable way to restore
XAResources <
https://java.net/jira/browse/JTA_SPEC-2> Unassigned
paul_parkinson
<
https://java.net/jira/secure/ViewProfile.jspa?name=paul_parkinson>
Minor Open Open UNRESOLVED 07/Aug/12 07/Aug/12
/Actions/
<
https://java.net/jira/rest/api/1.0/issues/116326/ActionsAndOperations>
--
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)
--
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Paul Hickey (Ireland), Matt Parson
(USA), Charlie Peters (USA)