On 18/05/16 16:53, Jon Hawkes wrote:
> Hi
>
> My straw man would be an additional integer element for commit priority
> on <resource-ref> (and @Resource). I think that would be most intuitive
> for developers and provide maximum flexibility.
Fine as far as it goes, but neither of those are under JTA spec control,
which means we can't just decide to change them, we need to get their
spec owners onboard with it. It also means we're not solving the whole
problem, since whatever non-JTA component of the stack implements those
still needs a spec-defined way to pass the information down to the JTA
itself. Are we thinking in terms of
registerSynchronization(Synchronization s, int priority)
enlistResource(XAResource resource, int priority)
> The reason I asked about specific requirements for a new properties
> parameter to TM/UT.begin() is that we'd probably need to come up with a
> way of standardizing the property keys and their meanings - something
> along the lines of: "javax.transaction.Transactional.timeout" => timeout
> applied to the transaction started by this annotation. Adding begin(int
> timeout) would be less onerous but not very future-proof.
So you are advocating the begin(Properties p) or
begin(Map<String,Object> p) route as being more extensible than
begin(long timeout), with initially just the one property key/value
defined by the spec? Though I guess we probably want to reserve a key
prefix for future spec use e.g. "javax.transaction.*"
Jonathan.
>
> Thanks
> Jon
>
>
>
> From: Jonathan Halliday <jonathan.halliday_at_redhat.com>
> To: users_at_jta-spec.java.net
> Date: 17/05/2016 14:40
> Subject: [jta-spec users] Re: shall we crack on? :) ...
> ------------------------------------------------------------------------
>
>
>
>
> On 17/05/16 14:02, Jon Hawkes wrote:
>> Hello
>>
>> I'm happy with these as the top priorities.
>>
>> I'd like the commit priority specification to enable users to precisely
>> prioritise the ordering of an arbitrary number of resources. It should
>> be possible for different applications to use the same resources with
>> different priorities.
>>
>
> Care to put up a straw-man proposal?
>
> I'm leaning towards semantic levels, e.g. enlistResource(myXAResource,
> Order.LRCO) or registerSynchronization(mySynch, Order.CACHE_FLUSH), but
> that would suffice only in so far as we identify the use cases up front.
>
> Integer levels (as with e.g. thread priority) would be more flexible,
> but suffer the same problem as with interposed synchronizations -
> everyone just goes for the highest level and then we're right back to
> square one.
>
> It's also feasible to have the user register a callback 'sort' function
> that the JTA would invoke, but at present the XAResource|Synchronization
> don't expose enough information to be meaningfully comparable.
>
>> The addition of timeout to @Transactional seems uncontroversial. Has
>> there been any call for adding a properties parameter to UT.begin() or
>> was that just proposed for symmetry?
>
> The issue is with the pairing of JTA and CDI implementations. I want a
> JTA to use fully capable in a non-CDI environment, or when paired with
> any 3rd party spec compliant CDI. The result of which is, the JTA
> itself needs something that the user or CDI impl can call to actually
> execute their intent. The annotation may be commonly used by JavaEE
> developers, but containers need a way to implement it, which is a
> parameter to begin().
>
> Jonathan.
>
>
>>
>> Thanks
>> Jon
>>
>>
>>
>> From: Paul Parkinson <paul.parkinson_at_oracle.com>
>> To: users_at_jta-spec.java.net
>> Date: 12/05/2016 17:19
>> Subject: [jta-spec users] shall we crack on? :) ...
>> ------------------------------------------------------------------------
>>
>>
>>
>> Hello,
>>
>> So in our list of items we have these two priorities:
>>
>> - https://java.net/jira/browse/JTA_SPEC-4"support explicit ordering of
>> commits for XAResources enlisted in a transaction” .
>> There has been consensus for a while now that this is
>> the top priority issue and we’d been discussing the best way to make it
>> configurable (eg IBM WebSphere uses resource-ref config, Redhat WildFly
>> uses XAResource interface extension, etc.), therefore, I think the next
>> step here is to resolve that aspect.
>>
>> - https://java.net/jira/browse/JTA_SPEC-13"Add timeout attribute to the
>> javax.transaction.Transactional annotation” .
>> This is related to a topic that we’ve discussed here
>> since before this annotation which is standardizing the ability to pass
>> transaction properties (such as timeout) at an individual transaction
>> level. Again here we have options such as a new UT/TM.begin API that
>> takes either the transaction timeout or properties or both, the
>> attribute of the CDI Transactional annotation as mentioned in this
>> entry, etc.
>>
>> Thoughts?...
>>
>> Thanks,
>> Paul
>>
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander