I just want to bring this to everyone attention one more time.
The conversation scope concurrency control mechanism seems to be a frequent
point of pain in many projects.
Especially when working with browser triggered asynchronous requests, you
can not rely on client-sided request synchronization.
Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the
specified) BusyConversationException mitigating the effect a bit.
This is a rather strict un-configurable type of CC. Also its completely out
of alignment with the other build-in scopes, offering no CC what so ever.
In the cases of Session- and Application-Scope, thread handling is left
entirely to the developer, even so they are just as vulnerable in AJAX
environments.
We should really consider introducing a common configurable mechanism, that
is aligned across all scopes (obviously accounting for backwards
compatibility in the case of conversation scope).
Would really appreciate some feedback.
Kind regards,
Stephan
On Mon, 22 Feb 2016 at 23:10 Reza Rahman <Reza.Rahman(a)oracle.com> wrote:
We've discussed this issue before. I definitely still think @Lock
belongs
in a modular CDI specification. It would be highly useful to both
@Singleton and @ApplicationScoped. Today if I need to use declarative
concurrency control for a shared component I am essentially forced to use
EJB singleton - which shouldn't be the case and perhaps should not have
been the case past Java EE 6.
On 2/19/2016 5:27 AM, Stephan Knitelius wrote:
Hi all,
CDI spec does not define a common concurrency control mechanism. The time
any type of concurrency control is mentioned is in conjunction with EJB and
a rather restrictive one for conversation context.
CDI Spec:
The container ensures that a long-running conversation may be associated
with at most one request at a time, by blocking or rejecting concurrent
requests. If the container rejects a request, it must associate the request
with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
It would be helpful if a common configurable concurrency mechanism (EJB
Singleton style locking?) could be established for all normal scopes.
What are your thoughts on this?
Regards,
Stephan
______________________________________
*Stephan Knitelius*
Alteburger Str. 274
50968 Köln / Cologne
Deutschland / Germany
stephan(a)knitelius.com
_______________________________________________
cdi-dev mailing
listcdi-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.