4:59 p.m.
This is not just a problem with this one feature but a much broader one involving
@Asynchronous, @Schedule and many others. Simply punting on this problem and not dealing
with this class of problems vigorously is rather foolish. It winds up doing what it has
done for years - undermining pretty much all efforts related to Java EE, especially
compared to the velocity and effectiveness by which the clear competitors to everything
Java EE solve these issues. In the end, we are collectively to blame for the dismal state
of affairs in Java EE land because of this sort of thing.
On Feb 25, 2016, at 4:18 PM, Emily Jiang <EMIJIANG(a)uk.ibm.com>
wrote:
It would be nice if JavaEE Concurrency defines @Lock as a CDI interceptor, similar to
@Transactional . Since the JavaEE Concurrency spec is stale as per you and Raze point out,
how about experiment in DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it
can be pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI should define
an addendum for EE integration. I think we should seriously think about this.
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: Stephan Knitelius <stephan(a)knitelius.com>
To: Reza Rahman <reza_rahman(a)lycos.com>, Martin Kouba
<mkouba(a)redhat.com>,
Cc: cdi-dev(a)lists.jboss.org
Date: 25/02/2016 20:26
Subject: Re: [cdi-dev] Concurrency Control
Sent by: cdi-dev-bounces(a)lists.jboss.org
Hi Martin,
yes this particular issue is about concurrent access control. You are right in pointing
out that the lock should be applied
to the whole been and only override-able on a per method basis (similar to EJB Singleton
style locking).
Regarding conversation context, its fair enough to point-out that weld allows for
configure the conversation lock timeout.
However this is only true for Weld, this should really be made part of the specification.
Even if we were to specify a standard way to configure conversation locked timeouts in
the CDI specification, it would
still make the conversation scope the odd one out of the lot. Hence it would be more
sensible to design a
common way to handle concurrent access.
Also I would argue that you cannot implement a common concurrent access control via
interceptors,
since the container will preempt any interceptor based attempt for conversation scoped
beans.
As Reza pointed out Oracle has no intend to reopen "Concurrency Utilities for Java
EE" at this time and is not
willing to hand it over to anyone else. The same seems to be true for JTA.
Stephan
On Thu, 25 Feb 2016 at 15:50 Reza Rahman <reza_rahman(a)lycos.com> wrote:
Oracle has pretty much clearly stated it has absolutely no intention of updating the Java
EE Concurrency Utilities specification any time soon. My guess is that it will also never
allow anyone else to update it either since it owns that specification. If this is a
valuable feature to the community (which I definitely think it is) I strongly suggest
taking advantage of the fact that this is a gray area and include it in a modular CDI
specification so this feature doesn't continue to remain locked into EJB for Java EE
users that need to more effectively use things like @Stereotype for service composition.
> On Feb 25, 2016, at 9:13 AM, Martin Kouba <mkouba(a)redhat.com> wrote:
>
> Hi Stephan,
>
> I like the idea of CDI interceptor solution you're proposing in your
> blogpost [1]. However, concurrency is a difficult topic. First of all,
> this only solves concurrent access to the bean instance (i.e.
> method-level locking) - the bean state is always up to the user. Also
> I'm not so sure it's a good idea to only apply @Lock at the method level
> (some methods are guarded some not - AFAIK EJB does not allow this either).
>
> I agree that conversation concurrentAccessTimeout in Weld should be
> configurable. In fact, it should be possible to change this timeout even
> now using Weld API and org.jboss.weld.context.ConversationContext. But
> it should be definitely more straightforward [2].
>
> To sum it up - I wouldn't add concurrency control to the spec provided
> it's implementable using interceptors. This is a similar situation as to
> javax.transaction.Transactional and JTA. The best place to specify this
> is IMHO "Concurrency Utilities for Java EE".
>
> Martin
>
> [1]
> http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/
>
> [2]
> https://issues.jboss.org/browse/WELD-2113
>
> Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a):
>> I just want to bring this to everyone attention one more time.
>>
>> The conversation scope concurrency control mechanism seems to be a
>> frequent point of pain in many projects.
>>
>> Especially when working with browser triggered asynchronous requests,
>> you can not rely on client-sided request synchronization.
>> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the
>> specified) BusyConversationException mitigating the effect a bit.
>>
>> This is a rather strict un-configurable type of CC. Also its
>> completely out of alignment with the other build-in scopes, offering no
>> CC what so ever.
>>
>> In the cases of Session- and Application-Scope, thread handling is left
>> entirely to the developer, even so they are just as vulnerable in AJAX
>> environments.
>>
>> We should really consider introducing a common configurable mechanism,
>> that is aligned across all scopes (obviously accounting for backwards
>> compatibility in the case of conversation scope).
>>
>> Would really appreciate some feedback.
>>
>> Kind regards,
>>
>> Stephan
>>
>>
>>
>>
>> On Mon, 22 Feb 2016 at 23:10 Reza Rahman <Reza.Rahman(a)oracle.com
>> <mailto:Reza.Rahman@oracle.com>> wrote:
>>
>> We've discussed this issue before. I definitely still think @Lock
>> belongs in a modular CDI specification. It would be highly useful to
>> both @Singleton and @ApplicationScoped. Today if I need to use
>> declarative concurrency control for a shared component I am
>> essentially forced to use EJB singleton - which shouldn't be the
>> case and perhaps should not have been the case past Java EE 6.
>>
>>
>>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote:
>>> Hi all,
>>>
>>> CDI spec does not define a common concurrency control mechanism.
>>> The time any type of concurrency control is mentioned is in
>>> conjunction with EJB and a rather restrictive one for conversation
>>> context.
>>>
>>> CDI Spec:
>>> The container ensures that a long-running conversation may be
>>> associated with at most one request at a time, by blocking or
>>> rejecting concurrent requests. If the container rejects a request,
>>> it must associate the request with a new transient conversation
>>> and throw an exception of
>>> type|javax.enterprise.context.BusyConversationException|.
>>>
>>>
>>> It would be helpful if a common configurable concurrency mechanism
>>> (EJB Singleton style locking?) could be established for all normal
>>> scopes.
>>>
>>> What are your thoughts on this?
>>>
>>> Regards,
>>>
>>> Stephan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ______________________________________
>>> *Stephan Knitelius*
>>> Alteburger Str. 274
>>> 50968 Köln / Cologne
>>> Deutschland / Germany
>>> stephan(a)knitelius.com <mailto:stephan@knitelius.com>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this
list, the provider waives all patent and other intellectual property rights inherent in
such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses
>> the code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>> ideas provided on this list, the provider waives all patent and
>> other intellectual property rights inherent in such information.
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For
all other ideas provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under
the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all
other ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such
information._______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
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
3:32 a.m.
New subject: Concurrency Control
Hi Reza,
I understand your frustration. I would suggest you raising a CDI jira to
get all options discussed. Any objections?
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: Reza Rahman <reza_rahman(a)lycos.com>
To: Emily Jiang/UK/IBM@IBMGB,
Cc: cdi-dev(a)lists.jboss.org
Date: 25/02/2016 23:01
Subject: Re: [cdi-dev] Concurrency Control
Sent by: cdi-dev-bounces(a)lists.jboss.org
This is not just a problem with this one feature but a much broader one
involving @Asynchronous, @Schedule and many others. Simply punting on this
problem and not dealing with this class of problems vigorously is rather
foolish. It winds up doing what it has done for years - undermining pretty
much all efforts related to Java EE, especially compared to the velocity
and effectiveness by which the clear competitors to everything Java EE
solve these issues. In the end, we are collectively to blame for the
dismal state of affairs in Java EE land because of this sort of thing.
On Feb 25, 2016, at 4:18 PM, Emily Jiang <EMIJIANG(a)uk.ibm.com> wrote:
It would be nice if JavaEE Concurrency defines @Lock as a CDI interceptor,
similar to @Transactional . Since the JavaEE Concurrency spec is stale as
per you and Raze point out, how about experiment in DeltaSpike? If
DeltaSpike provides the support of @Lock, maybe it can be pushed to JavaEE
concurrency as part of EE8 update. If not, maybe CDI should define an
addendum for EE integration. I think we should seriously think about this.
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: Stephan Knitelius <stephan(a)knitelius.com>
To: Reza Rahman <reza_rahman(a)lycos.com>, Martin Kouba <
mkouba(a)redhat.com>,
Cc: cdi-dev(a)lists.jboss.org
Date: 25/02/2016 20:26
Subject: Re: [cdi-dev] Concurrency Control
Sent by: cdi-dev-bounces(a)lists.jboss.org
Hi Martin,
yes this particular issue is about concurrent access control. You are
right in pointing out that the lock should be applied
to the whole been and only override-able on a per method basis (similar to
EJB Singleton style locking).
Regarding conversation context, its fair enough to point-out that weld
allows for configure the conversation lock timeout.
However this is only true for Weld, this should really be made part of the
specification.
Even if we were to specify a standard way to configure conversation locked
timeouts in the CDI specification, it would
still make the conversation scope the odd one out of the lot. Hence it
would be more sensible to design a
common way to handle concurrent access.
Also I would argue that you cannot implement a common concurrent access
control via interceptors,
since the container will preempt any interceptor based attempt for
conversation scoped beans.
As Reza pointed out Oracle has no intend to reopen "Concurrency Utilities
for Java EE" at this time and is not
willing to hand it over to anyone else. The same seems to be true for JTA.
Stephan
On Thu, 25 Feb 2016 at 15:50 Reza Rahman <reza_rahman(a)lycos.com> wrote:
Oracle has pretty much clearly stated it has absolutely no intention of
updating the Java EE Concurrency Utilities specification any time soon. My
guess is that it will also never allow anyone else to update it either
since it owns that specification. If this is a valuable feature to the
community (which I definitely think it is) I strongly suggest taking
advantage of the fact that this is a gray area and include it in a modular
CDI specification so this feature doesn't continue to remain locked into
EJB for Java EE users that need to more effectively use things like
@Stereotype for service composition.
On Feb 25, 2016, at 9:13 AM, Martin Kouba <mkouba(a)redhat.com>
wrote:
Hi Stephan,
I like the idea of CDI interceptor solution you're proposing in your
blogpost [1]. However, concurrency is a difficult topic. First of all,
this only solves concurrent access to the bean instance (i.e.
method-level locking) - the bean state is always up to the user. Also
I'm not so sure it's a good idea to only apply @Lock at the method level
(some methods are guarded some not - AFAIK EJB does not allow this
either).
I agree that conversation concurrentAccessTimeout in Weld should be
configurable. In fact, it should be possible to change this timeout even
now using Weld API and org.jboss.weld.context.ConversationContext. But
it should be definitely more straightforward [2].
To sum it up - I wouldn't add concurrency control to the spec provided
it's implementable using interceptors. This is a similar situation as to
javax.transaction.Transactional and JTA. The best place to specify this
is IMHO "Concurrency Utilities for Java EE".
Martin
[1]
http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/
[2]
https://issues.jboss.org/browse/WELD-2113
Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a):
> I just want to bring this to everyone attention one more time.
>
> The conversation scope concurrency control mechanism seems to be a
> frequent point of pain in many projects.
>
> Especially when working with browser triggered asynchronous requests,
> you can not rely on client-sided request synchronization.
> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the
> specified) BusyConversationException mitigating the effect a bit.
>
> This is a rather strict un-configurable type of CC. Also its
> completely out of alignment with the other build-in scopes, offering no
> CC what so ever.
>
> In the cases of Session- and Application-Scope, thread handling is left
> entirely to the developer, even so they are just as vulnerable in AJAX
> environments.
>
> We should really consider introducing a common configurable mechanism,
> that is aligned across all scopes (obviously accounting for backwards
> compatibility in the case of conversation scope).
>
> Would really appreciate some feedback.
>
> Kind regards,
>
> Stephan
>
>
>
>
> On Mon, 22 Feb 2016 at 23:10 Reza Rahman <Reza.Rahman(a)oracle.com
> <mailto:Reza.Rahman@oracle.com>> wrote:
>
> We've discussed this issue before. I definitely still think @Lock
> belongs in a modular CDI specification. It would be highly useful to
> both @Singleton and @ApplicationScoped. Today if I need to use
> declarative concurrency control for a shared component I am
> essentially forced to use EJB singleton - which shouldn't be the
> case and perhaps should not have been the case past Java EE 6.
>
>
>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote:
>> Hi all,
>>
>> CDI spec does not define a common concurrency control mechanism.
>> The time any type of concurrency control is mentioned is in
>> conjunction with EJB and a rather restrictive one for conversation
>> context.
>>
>> CDI Spec:
>> The container ensures that a long-running conversation may be
>> associated with at most one request at a time, by blocking or
>> rejecting concurrent requests. If the container rejects a request,
>> it must associate the request with a new transient conversation
>> and throw an exception of
>> type|javax.enterprise.context.BusyConversationException|.
>>
>>
>> It would be helpful if a common configurable concurrency mechanism
>> (EJB Singleton style locking?) could be established for all normal
>> scopes.
>>
>> What are your thoughts on this?
>>
>> Regards,
>>
>> Stephan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ______________________________________
>> *Stephan Knitelius*
>> Alteburger Str. 274
>> 50968 Köln / Cologne
>> Deutschland / Germany
>> stephan(a)knitelius.com <mailto:stephan@knitelius.com>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses
the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> ideas provided on this list, the provider waives all patent and
> other intellectual property rights inherent in such information.
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
code
under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under
the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
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
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
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
3:40 a.m.
New subject: Concurrency Control
Well, I don't like this approach. Seems like making CDI an "EJB.next
all-in-one spec". BTW there is already a JIRA issue [1]. Maybe a
separate issue should be created for conversation access timeout.
Martin
[1]
https://issues.jboss.org/browse/CDI-582
Dne 26.2.2016 v 10:32 Emily Jiang napsal(a):
Hi Reza,
I understand your frustration. I would suggest you raising a CDI jira to
get all options discussed. Any objections?
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: Reza Rahman <reza_rahman(a)lycos.com>
To: Emily Jiang/UK/IBM@IBMGB,
Cc: cdi-dev(a)lists.jboss.org
Date: 25/02/2016 23:01
Subject: Re: [cdi-dev] Concurrency Control
Sent by: cdi-dev-bounces(a)lists.jboss.org
------------------------------------------------------------------------
This is not just a problem with this one feature but a much broader one
involving @Asynchronous, @Schedule and many others. Simply punting on
this problem and not dealing with this class of problems vigorously is
rather foolish. It winds up doing what it has done for years -
undermining pretty much all efforts related to Java EE, especially
compared to the velocity and effectiveness by which the clear
competitors to everything Java EE solve these issues. In the end, we are
collectively to blame for the dismal state of affairs in Java EE land
because of this sort of thing.
On Feb 25, 2016, at 4:18 PM, Emily Jiang <_EMIJIANG(a)uk.ibm.com_
<mailto:EMIJIANG@uk.ibm.com>> wrote:
It would be nice if JavaEE Concurrency defines @Lock as a CDI
interceptor, similar to @Transactional . Since the JavaEE Concurrency
spec is stale as per you and Raze point out, how about experiment in
DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be
pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI
should define an addendum for EE integration. I think we should
seriously think about this.
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: _emijiang(a)uk.ibm.com_ <mailto:emijiang@uk.ibm.com>
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: Stephan Knitelius <_stephan(a)knitelius.com_
<mailto:stephan@knitelius.com>>
To: Reza Rahman <_reza_rahman(a)lycos.com_
<mailto:reza_rahman@lycos.com>>, Martin Kouba <_mkouba(a)redhat.com_
<mailto:mkouba@redhat.com>>,
Cc: _cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org>
Date: 25/02/2016 20:26
Subject: Re: [cdi-dev] Concurrency Control
Sent by: _cdi-dev-bounces(a)lists.jboss.org_
<mailto:cdi-dev-bounces@lists.jboss.org>
------------------------------------------------------------------------
Hi Martin,
yes this particular issue is about concurrent access control. You are
right in pointing out that the lock should be applied
to the whole been and only override-able on a per method basis (similar
to EJB Singleton style locking).
Regarding conversation context, its fair enough to point-out that weld
allows for configure the conversation lock timeout.
However this is only true for Weld, this should really be made part of
the specification.
Even if we were to specify a standard way to configure conversation
locked timeouts in the CDI specification, it would
still make the conversation scope the odd one out of the lot. Hence it
would be more sensible to design a
common way to handle concurrent access.
Also I would argue that you cannot implement a common concurrent access
control via interceptors,
since the container will preempt any interceptor based attempt for
conversation scoped beans.
As Reza pointed out Oracle has no intend to reopen "Concurrency
Utilities for Java EE" at this time and is not
willing to hand it over to anyone else. The same seems to be true for JTA.
Stephan
On Thu, 25 Feb 2016 at 15:50 Reza Rahman <_reza_rahman(a)lycos.com_
<mailto:reza_rahman@lycos.com>> wrote:
Oracle has pretty much clearly stated it has absolutely no intention of
updating the Java EE Concurrency Utilities specification any time soon.
My guess is that it will also never allow anyone else to update it
either since it owns that specification. If this is a valuable feature
to the community (which I definitely think it is) I strongly suggest
taking advantage of the fact that this is a gray area and include it in
a modular CDI specification so this feature doesn't continue to remain
locked into EJB for Java EE users that need to more effectively use
things like @Stereotype for service composition.
> On Feb 25, 2016, at 9:13 AM, Martin Kouba <_mkouba(a)redhat.com_
<mailto:mkouba@redhat.com>> wrote:
>
> Hi Stephan,
>
> I like the idea of CDI interceptor solution you're proposing in your
> blogpost [1]. However, concurrency is a difficult topic. First of all,
> this only solves concurrent access to the bean instance (i.e.
> method-level locking) - the bean state is always up to the user. Also
> I'm not so sure it's a good idea to only apply @Lock at the method level
> (some methods are guarded some not - AFAIK EJB does not allow this
either).
>
> I agree that conversation concurrentAccessTimeout in Weld should be
> configurable. In fact, it should be possible to change this timeout even
> now using Weld API and org.jboss.weld.context.ConversationContext. But
> it should be definitely more straightforward [2].
>
> To sum it up - I wouldn't add concurrency control to the spec provided
> it's implementable using interceptors. This is a similar situation as to
> javax.transaction.Transactional and JTA. The best place to specify this
> is IMHO "Concurrency Utilities for Java EE".
>
> Martin
>
> [1]
> _http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/_
>
> [2]
> _https://issues.jboss.org/browse/WELD-2113_
>
> Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a):
>> I just want to bring this to everyone attention one more time.
>>
>> The conversation scope concurrency control mechanism seems to be a
>> frequent point of pain in many projects.
>>
>> Especially when working with browser triggered asynchronous requests,
>> you can not rely on client-sided request synchronization.
>> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the
>> specified) BusyConversationException mitigating the effect a bit.
>>
>> This is a rather strict un-configurable type of CC. Also its
>> completely out of alignment with the other build-in scopes, offering no
>> CC what so ever.
>>
>> In the cases of Session- and Application-Scope, thread handling is left
>> entirely to the developer, even so they are just as vulnerable in AJAX
>> environments.
>>
>> We should really consider introducing a common configurable mechanism,
>> that is aligned across all scopes (obviously accounting for backwards
>> compatibility in the case of conversation scope).
>>
>> Would really appreciate some feedback.
>>
>> Kind regards,
>>
>> Stephan
>>
>>
>>
>>
>> On Mon, 22 Feb 2016 at 23:10 Reza Rahman <_Reza.Rahman(a)oracle.com_
<mailto:Reza.Rahman@oracle.com>
>> <mailto:_Reza.Rahman@oracle.com_
<mailto:Reza.Rahman@oracle.com>>>
wrote:
>>
>> We've discussed this issue before. I definitely still think @Lock
>> belongs in a modular CDI specification. It would be highly useful to
>> both @Singleton and @ApplicationScoped. Today if I need to use
>> declarative concurrency control for a shared component I am
>> essentially forced to use EJB singleton - which shouldn't be the
>> case and perhaps should not have been the case past Java EE 6.
>>
>>
>>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote:
>>> Hi all,
>>>
>>> CDI spec does not define a common concurrency control mechanism.
>>> The time any type of concurrency control is mentioned is in
>>> conjunction with EJB and a rather restrictive one for conversation
>>> context.
>>>
>>> CDI Spec:
>>> The container ensures that a long-running conversation may be
>>> associated with at most one request at a time, by blocking or
>>> rejecting concurrent requests. If the container rejects a request,
>>> it must associate the request with a new transient conversation
>>> and throw an exception of
>>> type|javax.enterprise.context.BusyConversationException|.
>>>
>>>
>>> It would be helpful if a common configurable concurrency mechanism
>>> (EJB Singleton style locking?) could be established for all normal
>>> scopes.
>>>
>>> What are your thoughts on this?
>>>
>>> Regards,
>>>
>>> Stephan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ______________________________________
>>> *Stephan Knitelius*
>>> Alteburger Str. 274
>>> 50968 Köln / Cologne
>>> Deutschland / Germany
>>> _stephan(a)knitelius.com_
<mailto:stephan@knitelius.com><mailto:_stephan@knitelius.com_
<mailto:stephan@knitelius.com>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> _cdi-dev(a)lists.jboss.org_
<mailto:cdi-dev@lists.jboss.org><mailto:_cdi-dev@lists.jboss.org_
<mailto:cdi-dev@lists.jboss.org>>
>>> _https://lists.jboss.org/mailman/listinfo/cdi-dev_
>>>
>>> Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2
(_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> _cdi-dev(a)lists.jboss.org_
<mailto:cdi-dev@lists.jboss.org><mailto:_cdi-dev@lists.jboss.org_
<mailto:cdi-dev@lists.jboss.org>>
>> _https://lists.jboss.org/mailman/listinfo/cdi-dev_
>>
>> Note that for all code provided on this list, the provider licenses
>> the code under the Apache License, Version 2
>> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other
>> ideas provided on this list, the provider waives all patent and
>> other intellectual property rights inherent in such information.
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> _cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org>
>> _https://lists.jboss.org/mailman/listinfo/cdi-dev_
>>
>> Note that for all code provided on this list, the provider licenses
the code under the Apache License, Version 2
(_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> _cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org>
> _https://lists.jboss.org/mailman/listinfo/cdi-dev_
>
> Note that for all code provided on this list, the provider licenses
the code under the Apache License, Version 2
(_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such
information._______________________________________________
cdi-dev mailing list_
__cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org>_
__https://lists.jboss.org/mailman/listinfo/cdi-dev_
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2
(_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
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_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
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
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
5:15 a.m.
New subject: Concurrency Control
Thank you Martin for pointing out CDI-582! Then we should log comments on
the jira. Maybe Atoine has a better suggestion on how to handle this cross
spec issue. Addressing the conversation access timeout in CDI might be a
step forward.
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: Martin Kouba <mkouba(a)redhat.com To:
Emily Jiang/UK/IBM@IBMGB, Reza Rahman <reza_rahman(a)lycos.com>,
Cc: cdi-dev(a)lists.jboss.org
Date: 26/02/2016 09:41
Subject: Re: [cdi-dev] Concurrency Control
Sent by: cdi-dev-bounces(a)lists.jboss.org
Well, I don't like this approach. Seems like making CDI an "EJB.next
all-in-one spec". BTW there is already a JIRA issue [1]. Maybe a
separate issue should be created for conversation access timeout.
Martin
[1]
https://issues.jboss.org/browse/CDI-582
Dne 26.2.2016 v 10:32 Emily Jiang napsal(a):
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
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
Hi Reza,
I understand your frustration. I would suggest you raising a CDI jira to
get all options discussed. Any objections?
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: Reza Rahman <reza_rahman(a)lycos.com To:
Emily Jiang/UK/IBM@IBMGB,
Cc: cdi-dev(a)lists.jboss.org
Date: 25/02/2016 23:01
Subject: Re: [cdi-dev] Concurrency Control
Sent by: cdi-dev-bounces(a)lists.jboss.org
------------------------------------------------------------------------
This is not just a problem with this one feature but a much broader one
involving @Asynchronous, @Schedule and many others. Simply punting on
this problem and not dealing with this class of problems vigorously is
rather foolish. It winds up doing what it has done for years -
undermining pretty much all efforts related to Java EE, especially
compared to the velocity and effectiveness by which the clear
competitors to everything Java EE solve these issues. In the end, we are
collectively to blame for the dismal state of affairs in Java EE land
because of this sort of thing.
On Feb 25, 2016, at 4:18 PM, Emily Jiang <_EMIJIANG(a)uk.ibm.com_
<mailto:EMIJIANG@uk.ibm.com>> wrote:
It would be nice if JavaEE Concurrency defines @Lock as a CDI
interceptor, similar to @Transactional . Since the JavaEE Concurrency
spec is stale as per you and Raze point out, how about experiment in
DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be
pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI
should define an addendum for EE integration. I think we should
seriously think about this.
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: _emijiang(a)uk.ibm.com_ <mailto:emijiang@uk.ibm.com Lotus
Notes: Emily Jiang/UK/IBM@IBMGB
From: Stephan Knitelius <_stephan(a)knitelius.com_
<mailto:stephan@knitelius.com> To: Reza
Rahman <_reza_rahman(a)lycos.com_
<mailto:reza_rahman@lycos.com>>, Martin Kouba <_mkouba(a)redhat.com_
<mailto:mkouba@redhat.com>>,
Cc: _cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org Date: 25/02/2016 20:26
Subject: Re: [cdi-dev] Concurrency Control
Sent by: _cdi-dev-bounces(a)lists.jboss.org_
<mailto:cdi-dev-bounces@lists.jboss.org
------------------------------------------------------------------------
Hi Martin,
yes this particular issue is about concurrent access control. You are
right in pointing out that the lock should be applied
to the whole been and only override-able on a per method basis (similar
to EJB Singleton style locking).
Regarding conversation context, its fair enough to point-out that weld
allows for configure the conversation lock timeout.
However this is only true for Weld, this should really be made part of
the specification.
Even if we were to specify a standard way to configure conversation
locked timeouts in the CDI specification, it would
still make the conversation scope the odd one out of the lot. Hence it
would be more sensible to design a
common way to handle concurrent access.
Also I would argue that you cannot implement a common concurrent access
control via interceptors,
since the container will preempt any interceptor based attempt for
conversation scoped beans.
As Reza pointed out Oracle has no intend to reopen "Concurrency
Utilities for Java EE" at this time and is not
willing to hand it over to anyone else. The same seems to be true for
JTA.
Stephan
On Thu, 25 Feb 2016 at 15:50 Reza Rahman <_reza_rahman(a)lycos.com_
<mailto:reza_rahman@lycos.com>> wrote:
Oracle has pretty much clearly stated it has absolutely no intention of
updating the Java EE Concurrency Utilities specification any time soon.
My guess is that it will also never allow anyone else to update it
either since it owns that specification. If this is a valuable feature
to the community (which I definitely think it is) I strongly suggest
taking advantage of the fact that this is a gray area and include it in
a modular CDI specification so this feature doesn't continue to remain
locked into EJB for Java EE users that need to more effectively use
things like @Stereotype for service composition.
> On Feb 25, 2016, at 9:13 AM, Martin Kouba <_mkouba(a)redhat.com_
<mailto:mkouba@redhat.com>> wrote:
> Hi Stephan,
> I like the idea of CDI interceptor solution you're
proposing in your
> blogpost [1]. However, concurrency is a difficult topic. First of
all,
> this only solves concurrent access to the bean instance (i.e.
> method-level locking) - the bean state is always up to the user. Also
> I'm not so sure it's a good idea to only apply @Lock at the method
level
> (some methods are guarded some not - AFAIK EJB does not allow
this
either).
> I agree that conversation concurrentAccessTimeout in
Weld should be
> configurable. In fact, it should be possible to change this timeout
even
> now using Weld API and
org.jboss.weld.context.ConversationContext.
But
> it should be definitely more straightforward [2].
> To sum it up - I wouldn't add concurrency control to
the spec
provided
> it's implementable using interceptors. This is a similar
situation as
to
> javax.transaction.Transactional and JTA. The best place to
specify
this
> is IMHO "Concurrency Utilities for Java EE".
> Martin
> [1]
> _http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/_
> [2]
> _https://issues.jboss.org/browse/WELD-2113_
> Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a):
>> I just want to bring this to everyone attention one more time.
> >> The conversation scope concurrency control mechanism
seems to be a
>> frequent point of pain in many projects.
> >> Especially when working with browser triggered
asynchronous
requests,
>> you can not rely on client-sided request synchronization.
>> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the
>> specified) BusyConversationException mitigating the effect a bit.
> >> This is a rather strict un-configurable type of CC.
Also its
>> completely out of alignment with the other build-in scopes, offering
no
>> CC what so ever.
> >> In the cases of Session- and Application-Scope,
thread handling is
left
>> entirely to the developer, even so they are just as
vulnerable in
AJAX
>> environments.
> >> We should really consider introducing a common
configurable
mechanism,
>> that is aligned across all scopes (obviously accounting for
backwards
>> compatibility in the case of conversation scope).
> >> Would really appreciate some feedback.
> >> Kind regards,
> >> Stephan
> > >
> >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman
<_Reza.Rahman(a)oracle.com_
<mailto:Reza.Rahman@oracle.com >>
<mailto:_Reza.Rahman@oracle.com_ <mailto:Reza.Rahman@oracle.com>> wrote:
> >> We've discussed this issue before. I
definitely still think @Lock
>> belongs in a modular CDI specification. It would be highly useful
to
>> both @Singleton and @ApplicationScoped. Today if I need
to use
>> declarative concurrency control for a shared component I am
>> essentially forced to use EJB singleton - which shouldn't be the
>> case and perhaps should not have been the case past Java EE 6.
> > >>> On 2/19/2016 5:27
AM, Stephan Knitelius wrote:
>>> Hi all,
>> >>> CDI spec does not
define a common concurrency control mechanism.
>>> The time any type of concurrency control is mentioned is in
>>> conjunction with EJB and a rather restrictive one for
conversation
>>> context.
>> >>> CDI Spec:
>>> The container ensures that a long-running conversation may be
>>> associated with at most one request at a time, by blocking or
>>> rejecting concurrent requests. If the container rejects a
request,
>>> it must associate the request with a new transient
conversation
>>> and throw an exception of
>>> type|javax.enterprise.context.BusyConversationException|.
>> >> >>> It would be helpful if a common configurable
concurrency
mechanism
>>> (EJB Singleton style locking?) could be established
for all
normal
>>> scopes.
>> >>> What are your
thoughts on this?
>> >>> Regards,
>> >>> Stephan
>> >> >>
>> >> >>
>> >> >>
>> >>>
______________________________________
>>> *Stephan Knitelius*
>>> Alteburger Str. 274
>>> 50968 Köln / Cologne
>>> Deutschland / Germany
>>> _stephan(a)knitelius.com_
<mailto:stephan@knitelius.com><mailto:_stephan@knitelius.com_
<mailto:stephan@knitelius.com>
>> >> >>>
_______________________________________________
>>> cdi-dev mailing list
>>> _cdi-dev(a)lists.jboss.org_
<mailto:cdi-dev@lists.jboss.org><mailto:_cdi-dev@lists.jboss.org_
<mailto:cdi-dev@lists.jboss.org>
>>> _https://lists.jboss.org/mailman/listinfo/cdi-dev_
>> >>> Note that for all
code provided on this list, the provider
licenses the code under the Apache License, Version 2
(_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
> >> _______________________________________________
>> cdi-dev mailing list
>> _cdi-dev(a)lists.jboss.org_
<mailto:cdi-dev@lists.jboss.org><mailto:_cdi-dev@lists.jboss.org_
<mailto:cdi-dev@lists.jboss.org>
>> _https://lists.jboss.org/mailman/listinfo/cdi-dev_
> >> Note that for all code provided on this list, the
provider
licenses
>> the code under the Apache License, Version 2
>> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all
other
>> ideas provided on this list, the provider waives all
patent and
>> other intellectual property rights inherent in such information.
> > >
>> _______________________________________________
>> cdi-dev mailing list
>> _cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org >> _https://lists.jboss.org/mailman/listinfo/cdi-dev_
> >> Note that for all code provided on this list, the
provider licenses
the code under the Apache License, Version 2
(_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> _cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org > _https://lists.jboss.org/mailman/listinfo/cdi-dev_
> Note that for all code provided on this list, the
provider licenses
the code under the Apache License, Version 2
(_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such
information._______________________________________________
cdi-dev mailing list_
__cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org>_
__https://lists.jboss.org/mailman/listinfo/cdi-dev_
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2
(_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
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_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
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
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under
the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
5:47 a.m.
New subject: Concurrency Control
Frankly I think the "we don't want scope creep" thinking on this EG has gone
a bit too far. Some things are indeed OK as core DI concerns. For example, it's not as
though I am suggesting CDI 2 take up the MDB alignment work that belongs in JMS.next. This
EG should be thinking about what it needs to do to increase adoption. Finding reasonable
ways to get rid of EJB and becoming a bit more competitive with other DI frameworks
definitely helps.
On Feb 26, 2016, at 4:40 AM, Martin Kouba <mkouba(a)redhat.com>
wrote:
Well, I don't like this approach. Seems like making CDI an "EJB.next all-in-one
spec". BTW there is already a JIRA issue [1]. Maybe a separate issue should be
created for conversation access timeout.
Martin
[1]
https://issues.jboss.org/browse/CDI-582
Dne 26.2.2016 v 10:32 Emily Jiang napsal(a):
> Hi Reza,
>
> I understand your frustration. I would suggest you raising a CDI jira to
> get all options discussed. Any objections?
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone: +44 (0)1962 816278 Internal: 246278
>
> Email: emijiang(a)uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Reza Rahman <reza_rahman(a)lycos.com>
> To: Emily Jiang/UK/IBM@IBMGB,
> Cc: cdi-dev(a)lists.jboss.org
> Date: 25/02/2016 23:01
> Subject: Re: [cdi-dev] Concurrency Control
> Sent by: cdi-dev-bounces(a)lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> This is not just a problem with this one feature but a much broader one
> involving @Asynchronous, @Schedule and many others. Simply punting on
> this problem and not dealing with this class of problems vigorously is
> rather foolish. It winds up doing what it has done for years -
> undermining pretty much all efforts related to Java EE, especially
> compared to the velocity and effectiveness by which the clear
> competitors to everything Java EE solve these issues. In the end, we are
> collectively to blame for the dismal state of affairs in Java EE land
> because of this sort of thing.
>
> On Feb 25, 2016, at 4:18 PM, Emily Jiang <_EMIJIANG(a)uk.ibm.com_
> <mailto:EMIJIANG@uk.ibm.com>> wrote:
>
> It would be nice if JavaEE Concurrency defines @Lock as a CDI
> interceptor, similar to @Transactional . Since the JavaEE Concurrency
> spec is stale as per you and Raze point out, how about experiment in
> DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be
> pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI
> should define an addendum for EE integration. I think we should
> seriously think about this.
>
>
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone: +44 (0)1962 816278 Internal: 246278
>
> Email: _emijiang(a)uk.ibm.com_ <mailto:emijiang@uk.ibm.com>
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Stephan Knitelius <_stephan(a)knitelius.com_
> <mailto:stephan@knitelius.com>>
> To: Reza Rahman <_reza_rahman(a)lycos.com_
> <mailto:reza_rahman@lycos.com>>, Martin Kouba <_mkouba(a)redhat.com_
> <mailto:mkouba@redhat.com>>,
> Cc: _cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org>
> Date: 25/02/2016 20:26
> Subject: Re: [cdi-dev] Concurrency Control
> Sent by: _cdi-dev-bounces(a)lists.jboss.org_
> <mailto:cdi-dev-bounces@lists.jboss.org>
> ------------------------------------------------------------------------
>
>
>
> Hi Martin,
>
> yes this particular issue is about concurrent access control. You are
> right in pointing out that the lock should be applied
> to the whole been and only override-able on a per method basis (similar
> to EJB Singleton style locking).
>
> Regarding conversation context, its fair enough to point-out that weld
> allows for configure the conversation lock timeout.
> However this is only true for Weld, this should really be made part of
> the specification.
>
> Even if we were to specify a standard way to configure conversation
> locked timeouts in the CDI specification, it would
> still make the conversation scope the odd one out of the lot. Hence it
> would be more sensible to design a
> common way to handle concurrent access.
>
> Also I would argue that you cannot implement a common concurrent access
> control via interceptors,
> since the container will preempt any interceptor based attempt for
> conversation scoped beans.
>
> As Reza pointed out Oracle has no intend to reopen "Concurrency
> Utilities for Java EE" at this time and is not
> willing to hand it over to anyone else. The same seems to be true for JTA.
>
> Stephan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, 25 Feb 2016 at 15:50 Reza Rahman <_reza_rahman(a)lycos.com_
> <mailto:reza_rahman@lycos.com>> wrote:
> Oracle has pretty much clearly stated it has absolutely no intention of
> updating the Java EE Concurrency Utilities specification any time soon.
> My guess is that it will also never allow anyone else to update it
> either since it owns that specification. If this is a valuable feature
> to the community (which I definitely think it is) I strongly suggest
> taking advantage of the fact that this is a gray area and include it in
> a modular CDI specification so this feature doesn't continue to remain
> locked into EJB for Java EE users that need to more effectively use
> things like @Stereotype for service composition.
>
> > On Feb 25, 2016, at 9:13 AM, Martin Kouba <_mkouba(a)redhat.com_
> <mailto:mkouba@redhat.com>> wrote:
> >
> > Hi Stephan,
> >
> > I like the idea of CDI interceptor solution you're proposing in your
> > blogpost [1]. However, concurrency is a difficult topic. First of all,
> > this only solves concurrent access to the bean instance (i.e.
> > method-level locking) - the bean state is always up to the user. Also
> > I'm not so sure it's a good idea to only apply @Lock at the method
level
> > (some methods are guarded some not - AFAIK EJB does not allow this
> either).
> >
> > I agree that conversation concurrentAccessTimeout in Weld should be
> > configurable. In fact, it should be possible to change this timeout even
> > now using Weld API and org.jboss.weld.context.ConversationContext. But
> > it should be definitely more straightforward [2].
> >
> > To sum it up - I wouldn't add concurrency control to the spec provided
> > it's implementable using interceptors. This is a similar situation as to
> > javax.transaction.Transactional and JTA. The best place to specify this
> > is IMHO "Concurrency Utilities for Java EE".
> >
> > Martin
> >
> > [1]
> > _http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/_
> >
> > [2]
> > _https://issues.jboss.org/browse/WELD-2113_
> >
> > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a):
> >> I just want to bring this to everyone attention one more time.
> >>
> >> The conversation scope concurrency control mechanism seems to be a
> >> frequent point of pain in many projects.
> >>
> >> Especially when working with browser triggered asynchronous requests,
> >> you can not rely on client-sided request synchronization.
> >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the
> >> specified) BusyConversationException mitigating the effect a bit.
> >>
> >> This is a rather strict un-configurable type of CC. Also its
> >> completely out of alignment with the other build-in scopes, offering no
> >> CC what so ever.
> >>
> >> In the cases of Session- and Application-Scope, thread handling is left
> >> entirely to the developer, even so they are just as vulnerable in AJAX
> >> environments.
> >>
> >> We should really consider introducing a common configurable mechanism,
> >> that is aligned across all scopes (obviously accounting for backwards
> >> compatibility in the case of conversation scope).
> >>
> >> Would really appreciate some feedback.
> >>
> >> Kind regards,
> >>
> >> Stephan
> >>
> >>
> >>
> >>
> >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman <_Reza.Rahman(a)oracle.com_
> <mailto:Reza.Rahman@oracle.com>
> >> <mailto:_Reza.Rahman@oracle.com_
<mailto:Reza.Rahman@oracle.com>>>
> wrote:
> >>
> >> We've discussed this issue before. I definitely still think @Lock
> >> belongs in a modular CDI specification. It would be highly useful to
> >> both @Singleton and @ApplicationScoped. Today if I need to use
> >> declarative concurrency control for a shared component I am
> >> essentially forced to use EJB singleton - which shouldn't be the
> >> case and perhaps should not have been the case past Java EE 6.
> >>
> >>
> >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote:
> >>> Hi all,
> >>>
> >>> CDI spec does not define a common concurrency control mechanism.
> >>> The time any type of concurrency control is mentioned is in
> >>> conjunction with EJB and a rather restrictive one for conversation
> >>> context.
> >>>
> >>> CDI Spec:
> >>> The container ensures that a long-running conversation may be
> >>> associated with at most one request at a time, by blocking or
> >>> rejecting concurrent requests. If the container rejects a request,
> >>> it must associate the request with a new transient conversation
> >>> and throw an exception of
> >>> type|javax.enterprise.context.BusyConversationException|.
> >>>
> >>>
> >>> It would be helpful if a common configurable concurrency mechanism
> >>> (EJB Singleton style locking?) could be established for all normal
> >>> scopes.
> >>>
> >>> What are your thoughts on this?
> >>>
> >>> Regards,
> >>>
> >>> Stephan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ______________________________________
> >>> *Stephan Knitelius*
> >>> Alteburger Str. 274
> >>> 50968 Köln / Cologne
> >>> Deutschland / Germany
> >>> _stephan(a)knitelius.com_
> <mailto:stephan@knitelius.com><mailto:_stephan@knitelius.com_
> <mailto:stephan@knitelius.com>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cdi-dev mailing list
> >>> _cdi-dev(a)lists.jboss.org_
> <mailto:cdi-dev@lists.jboss.org><mailto:_cdi-dev@lists.jboss.org_
> <mailto:cdi-dev@lists.jboss.org>>
> >>> _https://lists.jboss.org/mailman/listinfo/cdi-dev_
> >>>
> >>> Note that for all code provided on this list, the provider
> licenses the code under the Apache License, Version 2
> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> _cdi-dev(a)lists.jboss.org_
> <mailto:cdi-dev@lists.jboss.org><mailto:_cdi-dev@lists.jboss.org_
> <mailto:cdi-dev@lists.jboss.org>>
> >> _https://lists.jboss.org/mailman/listinfo/cdi-dev_
> >>
> >> Note that for all code provided on this list, the provider licenses
> >> the code under the Apache License, Version 2
> >> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other
> >> ideas provided on this list, the provider waives all patent and
> >> other intellectual property rights inherent in such information.
> >>
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> _cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org>
> >> _https://lists.jboss.org/mailman/listinfo/cdi-dev_
> >>
> >> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2
> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> > --
> > Martin Kouba
> > Software Engineer
> > Red Hat, Czech Republic
> > _______________________________________________
> > cdi-dev mailing list
> > _cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org>
> > _https://lists.jboss.org/mailman/listinfo/cdi-dev_
> >
> > Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2
> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such
> information._______________________________________________
> cdi-dev mailing list_
> __cdi-dev(a)lists.jboss.org_ <mailto:cdi-dev@lists.jboss.org>_
> __https://lists.jboss.org/mailman/listinfo/cdi-dev_
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2
> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> 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_______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> 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
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under
the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all
other ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
3230
days inactive
3231
days old
4 comments
3 participants
participants (3)
-
Emily Jiang -
Martin Kouba -
Reza Rahman