I'll be there!
Mark.
On 12 Aug 2014, at 01:02, Paul Parkinson <paul.parkinson_at_oracle.com> 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)
>>>
>>
>
---
Mark Little
mlittle_at_redhat.com
JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).