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?
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.
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.
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.
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)