+1. Very good, timely ideas.
On 1/23/2014 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?
>
> 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)
>>
>