Hi all, CDI spec does not define a common concurrency control mechanism. The time any type of concurrency control is mentioned is in conjunction with EJB and a rather restrictive one for conversation context. CDI Spec: The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type|javax.enterprise.context.BusyConversationException|. It would be helpful if a common configurable concurrency mechanism (EJB Singleton style locking?) could be established for all normal scopes. What are your thoughts on this? Regards, Stephan ______________________________________ *Stephan Knitelius* Alteburger Str. 274 50968 Köln / Cologne Deutschland / Germany stephan(a)knitelius.com <mailto:stephan@knitelius.com> _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org 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.

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

Oracle has pretty much clearly stated it has absolutely no intention of updating the Java EE Concurrency Utilities specification any time soon. My guess is that it will also never allow anyone else to update it either since it owns that specification. If this is a valuable feature to the community (which I definitely think it is) I strongly suggest taking advantage of the fact that this is a gray area and include it in a modular CDI specification so this feature doesn't continue to remain locked into EJB for Java EE users that need to more effectively use things like @Stereotype for service composition. > On Feb 25, 2016, at 9:13 AM, Martin Kouba <mkouba(a)redhat.com&gt; wrote: > > Hi Stephan, > > I like the idea of CDI interceptor solution you're proposing in your > blogpost [1]. However, concurrency is a difficult topic. First of all, > this only solves concurrent access to the bean instance (i.e. > method-level locking) - the bean state is always up to the user. Also > I'm not so sure it's a good idea to only apply @Lock at the method level > (some methods are guarded some not - AFAIK EJB does not allow this either). > > I agree that conversation concurrentAccessTimeout in Weld should be > configurable. In fact, it should be possible to change this timeout even > now using Weld API and org.jboss.weld.context.ConversationContext. But > it should be definitely more straightforward [2]. > > To sum it up - I wouldn't add concurrency control to the spec provided > it's implementable using interceptors. This is a similar situation as to > javax.transaction.Transactional and JTA. The best place to specify this > is IMHO "Concurrency Utilities for Java EE". > > Martin > > [1] > http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/ > > [2] > https://issues.jboss.org/browse/WELD-2113 > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): >> I just want to bring this to everyone attention one more time. >> >> The conversation scope concurrency control mechanism seems to be a >> frequent point of pain in many projects. >> >> Especially when working with browser triggered asynchronous requests, >> you can not rely on client-sided request synchronization. >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the >> specified) BusyConversationException mitigating the effect a bit. >> >> This is a rather strict un-configurable type of CC. Also its >> completely out of alignment with the other build-in scopes, offering no >> CC what so ever. >> >> In the cases of Session- and Application-Scope, thread handling is left >> entirely to the developer, even so they are just as vulnerable in AJAX >> environments. >> >> We should really consider introducing a common configurable mechanism, >> that is aligned across all scopes (obviously accounting for backwards >> compatibility in the case of conversation scope). >> >> Would really appreciate some feedback. >> >> Kind regards, >> >> Stephan >> >> >> >> >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman <Reza.Rahman(a)oracle.com >> <mailto:Reza.Rahman@oracle.com>> wrote: >> >> We've discussed this issue before. I definitely still think @Lock >> belongs in a modular CDI specification. It would be highly useful to >> both @Singleton and @ApplicationScoped. Today if I need to use >> declarative concurrency control for a shared component I am >> essentially forced to use EJB singleton - which shouldn't be the >> case and perhaps should not have been the case past Java EE 6. >> >> >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: >>> Hi all, >>> >>> CDI spec does not define a common concurrency control mechanism. >>> The time any type of concurrency control is mentioned is in >>> conjunction with EJB and a rather restrictive one for conversation >>> context. >>> >>> CDI Spec: >>> The container ensures that a long-running conversation may be >>> associated with at most one request at a time, by blocking or >>> rejecting concurrent requests. If the container rejects a request, >>> it must associate the request with a new transient conversation >>> and throw an exception of >>> type|javax.enterprise.context.BusyConversationException|. >>> >>> >>> It would be helpful if a common configurable concurrency mechanism >>> (EJB Singleton style locking?) could be established for all normal >>> scopes. >>> >>> What are your thoughts on this? >>> >>> Regards, >>> >>> Stephan >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ______________________________________ >>> *Stephan Knitelius* >>> Alteburger Str. 274 >>> 50968 Köln / Cologne >>> Deutschland / Germany >>> stephan(a)knitelius.com <mailto:stephan@knitelius.com> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.