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
> <mailto: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
>> <mailto: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 <mailto: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>Unassignedpaul_parkinson
>>>>>>>> <https://java.net/jira/secure/ViewProfile.jspa?name=paul_parkinson>
>>>>>>>> MajorOpen OpenUNRESOLVED20/Aug/1204/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>Unassignedfrenchc
>>>>>>>> <https://java.net/jira/secure/ViewProfile.jspa?name=frenchc>Major
>>>>>>>> Open OpenUNRESOLVED30/Aug/1230/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>Unassignedpaul_parkinson
>>>>>>>> <https://java.net/jira/secure/ViewProfile.jspa?name=paul_parkinson>
>>>>>>>> MajorOpen OpenUNRESOLVED11/Oct/1211/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>Unassignedpaul_parkinson
>>>>>>>> <https://java.net/jira/secure/ViewProfile.jspa?name=paul_parkinson>
>>>>>>>> MajorOpen OpenUNRESOLVED10/Dec/1210/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>Unassignedpaul_parkinson
>>>>>>>> <https://java.net/jira/secure/ViewProfile.jspa?name=paul_parkinson>
>>>>>>>> MajorOpen OpenUNRESOLVED23/Aug/1323/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>
>>>>>>>> MinorOpen OpenUNRESOLVED07/Aug/1207/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)
>>>
>>
>