Concurrency Control

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Concurrency Control

Stephan Knitelius
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 typejavax.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
[hidden email]

_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

reza_rahman
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 typejavax.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
[hidden email]


_______________________________________________
cdi-dev mailing list
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Stephan Knitelius
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 <[hidden email]> 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 typejavax.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
[hidden email]


_______________________________________________
cdi-dev mailing list
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Martin Kouba
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 <[hidden email]
> <mailto:[hidden email]>> 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
>>     [hidden email] <mailto:[hidden email]>
>>
>>
>>     _______________________________________________
>>     cdi-dev mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     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
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Reza Rahman
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 <[hidden email]> 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>>    [hidden email] <mailto:[hidden email]>
>>>
>>>
>>>    _______________________________________________
>>>    cdi-dev mailing list
>>>    [hidden email] <mailto:[hidden email]>
>>>    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
>>    [hidden email] <mailto:[hidden email]>
>>    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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Stephan Knitelius
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>>    [hidden email] <mailto:[hidden email]>
>>>
>>>
>>>    _______________________________________________
>>>    cdi-dev mailing list
>>>    [hidden email] <mailto:[hidden email]>
>>>    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
>>    [hidden email] <mailto:[hidden email]>
>>    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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Emily Jiang
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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        Stephan Knitelius <[hidden email]>
To:        Reza Rahman <[hidden email]>, Martin Kouba <[hidden email]>,
Cc:        [hidden email]
Date:        25/02/2016 20:26
Subject:        Re: [cdi-dev] Concurrency Control
Sent by:        [hidden email]




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@...> 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@...> 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@...
>> <mailto:
Reza.Rahman@...>> 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@... <mailto:stephan@...>
>>>
>>>
>>>    _______________________________________________
>>>    cdi-dev mailing list
>>>   
[hidden email] <mailto:[hidden email]>
>>>   
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
>>   
[hidden email] <mailto:[hidden email]>
>>   
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
>>
[hidden email]
>>
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
>
[hidden email]
>
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Reza Rahman
In reply to this post by Stephan Knitelius
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 <[hidden email]> 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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        Stephan Knitelius <[hidden email]>
To:        Reza Rahman <[hidden email]>, Martin Kouba <[hidden email]>,
Cc:        [hidden email]
Date:        25/02/2016 20:26
Subject:        Re: [cdi-dev] Concurrency Control
Sent by:        [hidden email]




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 <[hidden email]> 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 <
[hidden email]> 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 <
[hidden email]
>> <mailto:
[hidden email]>> 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
>>>   
[hidden email] <mailto:[hidden email]>
>>>
>>>
>>>    _______________________________________________
>>>    cdi-dev mailing list
>>>   
[hidden email] <mailto:[hidden email]>
>>>   
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
>>   
[hidden email] <mailto:[hidden email]>
>>   
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
>>
[hidden email]
>>
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
>
[hidden email]
>
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Emily Jiang
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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        Reza Rahman <[hidden email]>
To:        Emily Jiang/UK/IBM@IBMGB,
Cc:        [hidden email]
Date:        25/02/2016 23:01
Subject:        Re: [cdi-dev] Concurrency Control
Sent by:        [hidden email]




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@...> 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@...
Lotus Notes: Emily Jiang/UK/IBM@IBMGB





From:        
Stephan Knitelius <stephan@...>
To:        
Reza Rahman <reza_rahman@...>, Martin Kouba <mkouba@...>,
Cc:        
[hidden email]
Date:        
25/02/2016 20:26
Subject:        
Re: [cdi-dev] Concurrency Control
Sent by:        
[hidden email]




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@...> 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@...> 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@...
>> <mailto:
Reza.Rahman@...>> 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@... <mailto:stephan@...>
>>>
>>>
>>>    _______________________________________________
>>>    cdi-dev mailing list
>>>    
[hidden email] <mailto:[hidden email]>
>>>    
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
>>    
[hidden email] <mailto:[hidden email]>
>>    
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
>>
[hidden email]
>>
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
>
[hidden email]
>
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

[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Martin Kouba
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: [hidden email]
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Reza Rahman <[hidden email]>
> To: Emily Jiang/UK/IBM@IBMGB,
> Cc: [hidden email]
> Date: 25/02/2016 23:01
> Subject: Re: [cdi-dev] Concurrency Control
> Sent by: [hidden email]
> ------------------------------------------------------------------------
>
>
>
> 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 <[hidden email].com_
> <mailto:[hidden email]>> 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: [hidden email].com_ <mailto:[hidden email]>
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Stephan Knitelius <_stephan@knitelius.com_
> <mailto:[hidden email]>>
> To: Reza Rahman <_reza_rahman@lycos.com_
> <mailto:[hidden email]>>, Martin Kouba <_mkouba@redhat.com_
> <mailto:[hidden email]>>,
> Cc: [hidden email].org_ <mailto:[hidden email]>
> Date: 25/02/2016 20:26
> Subject: Re: [cdi-dev] Concurrency Control
> Sent by: [hidden email].org_
> <mailto:[hidden email]>
> ------------------------------------------------------------------------
>
>
>
> 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@lycos.com_
> <mailto:[hidden email]>> 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@redhat.com_
> <mailto:[hidden email]>> 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@oracle.com_
> <mailto:[hidden email]>
>  >> <mailto:_Reza.Rahman@oracle.com_ <mailto:[hidden email]>>>
> 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@knitelius.com_
> <mailto:[hidden email]><mailto:_stephan@knitelius.com_
> <mailto:[hidden email]>>
>  >>>
>  >>>
>  >>>    _______________________________________________
>  >>>    cdi-dev mailing list
>  >>> [hidden email].org_
> <mailto:[hidden email]><mailto:[hidden email].org_
> <mailto:[hidden email]>>
>  >>> _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
>  >> [hidden email].org_
> <mailto:[hidden email]><mailto:[hidden email].org_
> <mailto:[hidden email]>>
>  >> _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
>  >> [hidden email].org_ <mailto:[hidden email]>
>  >> _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
>  > [hidden email].org_ <mailto:[hidden email]>
>  > _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_
> [hidden email].org_ <mailto:[hidden email]>_
> __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
> [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Emily Jiang
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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        Martin Kouba <[hidden email]>
To:        Emily Jiang/UK/IBM@IBMGB, Reza Rahman <[hidden email]>,
Cc:        [hidden email]
Date:        26/02/2016 09:41
Subject:        Re: [cdi-dev] Concurrency Control
Sent by:        [hidden email]




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: [hidden email]
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Reza Rahman <[hidden email]>
> To: Emily Jiang/UK/IBM@IBMGB,
> Cc: [hidden email]
> Date: 25/02/2016 23:01
> Subject: Re: [cdi-dev] Concurrency Control
> Sent by: [hidden email]
> ------------------------------------------------------------------------
>
>
>
> 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 <[hidden email].com_
> <
mailto:EMIJIANG@...>> 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: [hidden email].com_ <
mailto:emijiang@...>
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Stephan Knitelius <_stephan@knitelius.com_
> <
mailto:stephan@...>>
> To: Reza Rahman <_reza_rahman@lycos.com_
> <
mailto:reza_rahman@...>>, Martin Kouba <_mkouba@redhat.com_
> <
mailto:mkouba@...>>,
> Cc: [hidden email].org_ <
[hidden email]>
> Date: 25/02/2016 20:26
> Subject: Re: [cdi-dev] Concurrency Control
> Sent by: [hidden email].org_
> <
[hidden email]>
> ------------------------------------------------------------------------
>
>
>
> 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@lycos.com_
> <
mailto:reza_rahman@...>> 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@redhat.com_
> <
mailto:mkouba@...>> 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@oracle.com_
> <
mailto:Reza.Rahman@...>
>  >> <
mailto:_Reza.Rahman@oracle.com_ <mailto:Reza.Rahman@...>>>
> 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@knitelius.com_
> <
mailto:stephan@...><mailto:_stephan@knitelius.com_
> <
mailto:stephan@...>>
>  >>>
>  >>>
>  >>>    _______________________________________________
>  >>>    cdi-dev mailing list
>  >>> [hidden email].org_
> <
[hidden email]><[hidden email]
> <
[hidden email]>>
>  >>> _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
>  >> [hidden email].org_
> <
[hidden email]><[hidden email]
> <
[hidden email]>>
>  >> _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
>  >> [hidden email].org_ <
[hidden email]>
>  >> _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
>  > [hidden email].org_ <
[hidden email]>
>  > _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_
> [hidden email].org_ <
[hidden email]>_
> __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
> [hidden email]
>
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
> [hidden email]
>
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Reza Rahman
In reply to this post by Reza Rahman
No objections whatsoever. I will put in the JIRAs ASAP so we can give this the attention it deserves.

On Feb 26, 2016, at 4:32 AM, Emily Jiang <[hidden email]> wrote:

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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        Reza Rahman <[hidden email]>
To:        Emily Jiang/UK/IBM@IBMGB,
Cc:        [hidden email]
Date:        25/02/2016 23:01
Subject:        Re: [cdi-dev] Concurrency Control
Sent by:        [hidden email]




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 <
[hidden email]> 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:
[hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB





From:        
Stephan Knitelius <[hidden email]>
To:        
Reza Rahman <[hidden email]>, Martin Kouba <[hidden email]>,
Cc:        
[hidden email]
Date:        
25/02/2016 20:26
Subject:        
Re: [cdi-dev] Concurrency Control
Sent by:        
[hidden email]




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 <
[hidden email]> 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 <
[hidden email]> 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 <
[hidden email]
>> <mailto:
[hidden email]>> 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
>>>    
[hidden email] <mailto:[hidden email]>
>>>
>>>
>>>    _______________________________________________
>>>    cdi-dev mailing list
>>>    
[hidden email] <mailto:[hidden email]>
>>>    
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
>>    
[hidden email] <mailto:[hidden email]>
>>    
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
>>
[hidden email]
>>
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
>
[hidden email]
>
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

[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Reza Rahman
In reply to this post by Martin Kouba
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 <[hidden email]> 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: [hidden email]
>> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>>
>>
>>
>>
>> From: Reza Rahman <[hidden email]>
>> To: Emily Jiang/UK/IBM@IBMGB,
>> Cc: [hidden email]
>> Date: 25/02/2016 23:01
>> Subject: Re: [cdi-dev] Concurrency Control
>> Sent by: [hidden email]
>> ------------------------------------------------------------------------
>>
>>
>>
>> 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 <[hidden email].com_
>> <mailto:[hidden email]>> 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: [hidden email].com_ <mailto:[hidden email]>
>> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>>
>>
>>
>>
>> From: Stephan Knitelius <_stephan@knitelius.com_
>> <mailto:[hidden email]>>
>> To: Reza Rahman <_reza_rahman@lycos.com_
>> <mailto:[hidden email]>>, Martin Kouba <_mkouba@redhat.com_
>> <mailto:[hidden email]>>,
>> Cc: [hidden email].org_ <mailto:[hidden email]>
>> Date: 25/02/2016 20:26
>> Subject: Re: [cdi-dev] Concurrency Control
>> Sent by: [hidden email].org_
>> <mailto:[hidden email]>
>> ------------------------------------------------------------------------
>>
>>
>>
>> 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@lycos.com_
>> <mailto:[hidden email]>> 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@redhat.com_
>> <mailto:[hidden email]>> 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@oracle.com_
>> <mailto:[hidden email]>
>> >> <mailto:_Reza.Rahman@oracle.com_ <mailto:[hidden email]>>>
>> 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@knitelius.com_
>> <mailto:[hidden email]><mailto:_stephan@knitelius.com_
>> <mailto:[hidden email]>>
>> >>>
>> >>>
>> >>>    _______________________________________________
>> >>>    cdi-dev mailing list
>> >>> [hidden email].org_
>> <mailto:[hidden email]><mailto:[hidden email].org_
>> <mailto:[hidden email]>>
>> >>> _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
>> >> [hidden email].org_
>> <mailto:[hidden email]><mailto:[hidden email].org_
>> <mailto:[hidden email]>>
>> >> _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
>> >> [hidden email].org_ <mailto:[hidden email]>
>> >> _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
>> > [hidden email].org_ <mailto:[hidden email]>
>> > _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_
>> [hidden email].org_ <mailto:[hidden email]>_
>> __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
>> [hidden email]
>> 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
>> [hidden email]
>> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Werner Keil-2
In reply to this post by Stephan Knitelius
Reza/all,

One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. 

Similar to the even older JSR 107 which also has similar problems and technical debt (as members of this and other EGs confirmed or expressed their concern) 
We can't undo many of these problems, but it seems both these "relics" need at the very least a solid MR if not entirely new JSRs (before EE 8 wraps up the selected features) to address their age and fit in more nicely into the recent platform) JMS 2 did a great job in that direction and even has a new JSR for Java EE 8. 

Regards,

Werner 


On Fri, Feb 26, 2016 at 12:40 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Concurrency Control (Reza Rahman)


----------------------------------------------------------------------

Message: 1
Date: Fri, 26 Feb 2016 06:40:38 -0500
From: Reza Rahman <[hidden email]>
Subject: Re: [cdi-dev] Concurrency Control
To: Emily Jiang <[hidden email]>
Cc: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

No objections whatsoever. I will put in the JIRAs ASAP so we can give this the attention it deserves.

> On Feb 26, 2016, at 4:32 AM, Emily Jiang <[hidden email]> wrote:
>
> 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:  <a href="tel:%2B44%20%280%291962%20816278" value="+441962816278">+44 (0)1962 816278  Internal: 246278
>
> Email: [hidden email]
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From:        Reza Rahman <[hidden email]>
> To:        Emily Jiang/UK/IBM@IBMGB,
> Cc:        [hidden email]
> Date:        25/02/2016 23:01
> Subject:        Re: [cdi-dev] Concurrency Control
> Sent by:        [hidden email]
>
>
>
> 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 <[hidden email]> 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:  <a href="tel:%2B44%20%280%291962%20816278" value="+441962816278">+44 (0)1962 816278  Internal: 246278
>
> Email: [hidden email]
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From:        Stephan Knitelius <[hidden email]>
> To:        Reza Rahman <[hidden email]>, Martin Kouba <[hidden email]>,
> Cc:        [hidden email]
> Date:        25/02/2016 20:26
> Subject:        Re: [cdi-dev] Concurrency Control
> Sent by:        [hidden email]
>
>
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
> >> <mailto:[hidden email]>> 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
> >>>    [hidden email] <mailto:[hidden email]>
> >>>
> >>>
> >>>    _______________________________________________
> >>>    cdi-dev mailing list
> >>>    [hidden email] <mailto:[hidden email]>
> >>>    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
> >>    [hidden email] <mailto:[hidden email]>
> >>    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
> >> [hidden email]
> >> 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
> > [hidden email]
> > 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
> [hidden email]
> 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
> [hidden email]
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/525ab6e5/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
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.

End of cdi-dev Digest, Vol 63, Issue 36
***************************************


_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Reza Rahman
In parallel to whatever does or does not happen here, want to take up this discussion in the Java EE 8 EG? It will be good since you are an EG member and also had involvement in the EC. I think for now you can mention Stephan as a spec lead from the community with maybe Oracle being a co-spec lead to help ease any IP heartache that Oracle might get from this. What would be awesome of course is if Red Hat proposed to do this work and took over one more JSR from Oracle, but I won't hold my breadth on that one :-).

On Feb 26, 2016, at 11:39 AM, Werner Keil <[hidden email]> wrote:

Reza/all,

One of the biggest problems with can Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. 

Similar to the even older JSR 107 which also has similar problems and technical debt (as members of this and other EGs confirmed or expressed their concern) 
We can't undo many of these problems, but it seems both these "relics" need at the very least a solid MR if not entirely new JSRs (before EE 8 wraps up the selected features) to address their age and fit in more nicely into the recent platform) JMS 2 did a great job in that direction and even has a new JSR for Java EE 8. 

Regards,

Werner 


On Fri, Feb 26, 2016 at 12:40 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Concurrency Control (Reza Rahman)


----------------------------------------------------------------------

Message: 1
Date: Fri, 26 Feb 2016 06:40:38 -0500
From: Reza Rahman <[hidden email]>
Subject: Re: [cdi-dev] Concurrency Control
To: Emily Jiang <[hidden email]>
Cc: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

No objections whatsoever. I will put in the JIRAs ASAP so we can give this the attention it deserves.

> On Feb 26, 2016, at 4:32 AM, Emily Jiang <[hidden email]> wrote:
>
> 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:  <a href="tel:%2B44%20%280%291962%20816278" value="+441962816278">+44 (0)1962 816278  Internal: 246278
>
> Email: [hidden email]
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From:        Reza Rahman <[hidden email]>
> To:        Emily Jiang/UK/IBM@IBMGB,
> Cc:        [hidden email]
> Date:        25/02/2016 23:01
> Subject:        Re: [cdi-dev] Concurrency Control
> Sent by:        [hidden email]
>
>
>
> 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 <[hidden email]> 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:  <a href="tel:%2B44%20%280%291962%20816278" value="+441962816278">+44 (0)1962 816278  Internal: 246278
>
> Email: [hidden email]
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From:        Stephan Knitelius <[hidden email]>
> To:        Reza Rahman <[hidden email]>, Martin Kouba <[hidden email]>,
> Cc:        [hidden email]
> Date:        25/02/2016 20:26
> Subject:        Re: [cdi-dev] Concurrency Control
> Sent by:        [hidden email]
>
>
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
> >> <mailto:[hidden email]>> 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
> >>>    [hidden email] <mailto:[hidden email]>
> >>>
> >>>
> >>>    _______________________________________________
> >>>    cdi-dev mailing list
> >>>    [hidden email] <mailto:[hidden email]>
> >>>    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
> >>    [hidden email] <mailto:[hidden email]>
> >>    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
> >> [hidden email]
> >> 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
> > [hidden email]
> > 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
> [hidden email]
> 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
> [hidden email]
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/525ab6e5/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
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.

End of cdi-dev Digest, Vol 63, Issue 36
***************************************

_______________________________________________
cdi-dev mailing list
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Mark Struberg
In reply to this post by Werner Keil-2

> Am 26.02.2016 um 17:39 schrieb Werner Keil <[hidden email]>:
>
> Reza/all,
>
> One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI.
>

+1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today.  :/

Anyway, let’s not fight the past - we need a way forward.

LieGrue,
strub



_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Romain Manni-Bucau
At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt?


Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber

2016-02-28 19:16 GMT+01:00 Mark Struberg <[hidden email]>:

> Am 26.02.2016 um 17:39 schrieb Werner Keil <[hidden email]>:
>
> Reza/all,
>
> One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI.
>

+1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today.  :/

Anyway, let’s not fight the past - we need a way forward.

LieGrue,
strub



_______________________________________________
cdi-dev mailing list
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Reza Rahman
I am unsure what this means. Firstly I think this functionality is way overdue. Secondly I see little value to having anything that is a pseudo-standard. I'd rather see the effort pursue another path to standardization or remain completely independent while clearly pointing out what the obstacles to standardization are/were.

On the other hand if this is required to be implemented in Java EE 8 runtimes I don't think it matters what the particular structural gymnastics are. Purely from a JCP standpoint, it is possible to have a sub-specification but only if the eventual goal is to spin it out into a separate specification. Examples of this are JPA, interceptors and others. There is no precedent for an "incubator" specification that is somehow optional. In fact I am pretty sure the current JCP rules would disallow this.

On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau <[hidden email]> wrote:

At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt?


Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber

2016-02-28 19:16 GMT+01:00 Mark Struberg <[hidden email]>:

> Am 26.02.2016 um 17:39 schrieb Werner Keil <[hidden email]>:
>
> Reza/all,
>
> One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI.
>

+1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today.  :/

Anyway, let’s not fight the past - we need a way forward.

LieGrue,
strub



_______________________________________________
cdi-dev mailing list
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Werner Keil-2
In reply to this post by Stephan Knitelius
Yes, there's no "incubating" stage for JSRs other than "not Final", so as soon as a JSR or parts of it are final, they become part of an umbrella spec if that spec wants to contain them.

Potentially from Java EE 9 on there could be much finer grained activation or deactivation of features and profiles as soon as the whole Jigsaw thing and SE 9 is out, but until then I think we' have to stick to what's available right now. 

For CDI 2 modularity or running in Java SE are already in scope, but other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, I don't see how CDI should do things the platform will provide later anyway.

Regards,

Werner 


On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman <[hidden email]> wrote:
I am unsure what this means. Firstly I think this functionality is way overdue. Secondly I see little value to having anything that is a pseudo-standard. I'd rather see the effort pursue another path to standardization or remain completely independent while clearly pointing out what the obstacles to standardization are/were.

On the other hand if this is required to be implemented in Java EE 8 runtimes I don't think it matters what the particular structural gymnastics are. Purely from a JCP standpoint, it is possible to have a sub-specification but only if the eventual goal is to spin it out into a separate specification. Examples of this are JPA, interceptors and others. There is no precedent for an "incubator" specification that is somehow optional. In fact I am pretty sure the current JCP rules would disallow this.

On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau <[hidden email]> wrote:

At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt?


Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber

2016-02-28 19:16 GMT+01:00 Mark Struberg <[hidden email]>:

> Am 26.02.2016 um 17:39 schrieb Werner Keil <[hidden email]>:
>
> Reza/all,
>
> One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI.
>

+1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today.  :/

Anyway, let’s not fight the past - we need a way forward.

LieGrue,
strub



_______________________________________________
cdi-dev mailing list
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Control

Romain Manni-Bucau

2016-02-28 20:08 GMT+01:00 Werner Keil <[hidden email]>:
Yes, there's no "incubating" stage for JSRs other than "not Final", so as soon as a JSR or parts of it are final, they become part of an umbrella spec if that spec wants to contain them.

Potentially from Java EE 9 on there could be much finer grained activation or deactivation of features and profiles as soon as the whole Jigsaw thing and SE 9 is out, but until then I think we' have to stick to what's available right now. 

For CDI 2 modularity or running in Java SE are already in scope, but other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, I don't see how CDI should do things the platform will provide later anyway.


Fully agree, means @Lock shouldnt go in CDI as everyone stated so falling back on CDI cause concurrency spec is inactive is a bad choice. Question leaves CDI list then and is: how to make concurrency active?
 
Regards,

Werner 


On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman <[hidden email]> wrote:
I am unsure what this means. Firstly I think this functionality is way overdue. Secondly I see little value to having anything that is a pseudo-standard. I'd rather see the effort pursue another path to standardization or remain completely independent while clearly pointing out what the obstacles to standardization are/were.

On the other hand if this is required to be implemented in Java EE 8 runtimes I don't think it matters what the particular structural gymnastics are. Purely from a JCP standpoint, it is possible to have a sub-specification but only if the eventual goal is to spin it out into a separate specification. Examples of this are JPA, interceptors and others. There is no precedent for an "incubator" specification that is somehow optional. In fact I am pretty sure the current JCP rules would disallow this.

On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau <[hidden email]> wrote:

At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt?


Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber

2016-02-28 19:16 GMT+01:00 Mark Struberg <[hidden email]>:

> Am 26.02.2016 um 17:39 schrieb Werner Keil <[hidden email]>:
>
> Reza/all,
>
> One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI.
>

+1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today.  :/

Anyway, let’s not fight the past - we need a way forward.

LieGrue,
strub



_______________________________________________
cdi-dev mailing list
[hidden email]
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
[hidden email]
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
[hidden email]
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.
12