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)