[cdi-dev] Concurrency Control

Martin Kouba mkouba at redhat.com
Fri Feb 26 04:40:59 EST 2016


Well, I don't like this approach. Seems like making CDI an "EJB.next 
all-in-one spec". BTW there is already a JIRA issue [1]. Maybe a 
separate issue should be created for conversation access timeout.

Martin

[1]
https://issues.jboss.org/browse/CDI-582

Dne 26.2.2016 v 10:32 Emily Jiang napsal(a):
> Hi Reza,
>
> I understand your frustration. I would suggest you raising a CDI jira to
> get all options discussed. Any objections?
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emijiang at uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM at IBMGB
>
>
>
>
> From: Reza Rahman <reza_rahman at lycos.com>
> To: Emily Jiang/UK/IBM at IBMGB,
> Cc: cdi-dev at lists.jboss.org
> Date: 25/02/2016 23:01
> Subject: Re: [cdi-dev] Concurrency Control
> Sent by: cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> This is not just a problem with this one feature but a much broader one
> involving @Asynchronous, @Schedule and many others. Simply punting on
> this problem and not dealing with this class of problems vigorously is
> rather foolish. It winds up doing what it has done for years -
> undermining pretty much all efforts related to Java EE, especially
> compared to the velocity and effectiveness by which the clear
> competitors to everything Java EE solve these issues. In the end, we are
> collectively to blame for the dismal state of affairs in Java EE land
> because of this sort of thing.
>
> On Feb 25, 2016, at 4:18 PM, Emily Jiang <_EMIJIANG at uk.ibm.com_
> <mailto:EMIJIANG at uk.ibm.com>> wrote:
>
> It would be nice if JavaEE Concurrency defines @Lock as a CDI
> interceptor, similar to @Transactional . Since the JavaEE Concurrency
> spec is stale as per you and Raze point out, how about experiment in
> DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be
> pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI
> should define an addendum for EE integration. I think we should
> seriously think about this.
>
>
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: _emijiang at uk.ibm.com_ <mailto:emijiang at uk.ibm.com>
> Lotus Notes: Emily Jiang/UK/IBM at IBMGB
>
>
>
>
> From: Stephan Knitelius <_stephan at knitelius.com_
> <mailto:stephan at knitelius.com>>
> To: Reza Rahman <_reza_rahman at lycos.com_
> <mailto:reza_rahman at lycos.com>>, Martin Kouba <_mkouba at redhat.com_
> <mailto:mkouba at redhat.com>>,
> Cc: _cdi-dev at lists.jboss.org_ <mailto:cdi-dev at lists.jboss.org>
> Date: 25/02/2016 20:26
> Subject: Re: [cdi-dev] Concurrency Control
> Sent by: _cdi-dev-bounces at lists.jboss.org_
> <mailto:cdi-dev-bounces at lists.jboss.org>
> ------------------------------------------------------------------------
>
>
>
> Hi Martin,
>
> yes this particular issue is about concurrent access control. You are
> right in pointing out that the lock should be applied
> to the whole been and only override-able on a per method basis (similar
> to EJB Singleton style locking).
>
> Regarding conversation context, its fair enough to point-out that weld
> allows for configure the conversation lock timeout.
> However this is only true for Weld, this should really be made part of
> the specification.
>
> Even if we were to specify a standard way to configure conversation
> locked timeouts in the CDI specification, it would
> still make the conversation scope the odd one out of the lot. Hence it
> would be more sensible to design a
> common way to handle concurrent access.
>
> Also I would argue that you cannot implement a common concurrent access
> control via interceptors,
> since the container will preempt any interceptor based attempt for
> conversation scoped beans.
>
> As Reza pointed out Oracle has no intend to reopen "Concurrency
> Utilities for Java EE" at this time and is not
> willing to hand it over to anyone else. The same seems to be true for JTA.
>
> Stephan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, 25 Feb 2016 at 15:50 Reza Rahman <_reza_rahman at lycos.com_
> <mailto:reza_rahman at lycos.com>> wrote:
> Oracle has pretty much clearly stated it has absolutely no intention of
> updating the Java EE Concurrency Utilities specification any time soon.
> My guess is that it will also never allow anyone else to update it
> either since it owns that specification. If this is a valuable feature
> to the community (which I definitely think it is) I strongly suggest
> taking advantage of the fact that this is a gray area and include it in
> a modular CDI specification so this feature doesn't continue to remain
> locked into EJB for Java EE users that need to more effectively use
> things like @Stereotype for service composition.
>
>  > On Feb 25, 2016, at 9:13 AM, Martin Kouba <_mkouba at redhat.com_
> <mailto:mkouba at redhat.com>> wrote:
>  >
>  > Hi Stephan,
>  >
>  > I like the idea of CDI interceptor solution you're proposing in your
>  > blogpost [1]. However, concurrency is a difficult topic. First of all,
>  > this only solves concurrent access to the bean instance (i.e.
>  > method-level locking) - the bean state is always up to the user. Also
>  > I'm not so sure it's a good idea to only apply @Lock at the method level
>  > (some methods are guarded some not - AFAIK EJB does not allow this
> either).
>  >
>  > I agree that conversation concurrentAccessTimeout in Weld should be
>  > configurable. In fact, it should be possible to change this timeout even
>  > now using Weld API and org.jboss.weld.context.ConversationContext. But
>  > it should be definitely more straightforward [2].
>  >
>  > To sum it up - I wouldn't add concurrency control to the spec provided
>  > it's implementable using interceptors. This is a similar situation as to
>  > javax.transaction.Transactional and JTA. The best place to specify this
>  > is IMHO "Concurrency Utilities for Java EE".
>  >
>  > Martin
>  >
>  > [1]
>  > _http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/_
>  >
>  > [2]
>  > _https://issues.jboss.org/browse/WELD-2113_
>  >
>  > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a):
>  >> I just want to bring this to everyone attention one more time.
>  >>
>  >> The conversation scope concurrency control mechanism seems to be a
>  >> frequent point of pain in many projects.
>  >>
>  >> Especially when working with browser triggered asynchronous requests,
>  >> you can not rely on client-sided request synchronization.
>  >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the
>  >> specified) BusyConversationException mitigating the effect a bit.
>  >>
>  >> This is a rather strict un-configurable type of CC. Also its
>  >> completely out of alignment with the other build-in scopes, offering no
>  >> CC what so ever.
>  >>
>  >> In the cases of Session- and Application-Scope, thread handling is left
>  >> entirely to the developer, even so they are just as vulnerable in AJAX
>  >> environments.
>  >>
>  >> We should really consider introducing a common configurable mechanism,
>  >> that is aligned across all scopes (obviously accounting for backwards
>  >> compatibility in the case of conversation scope).
>  >>
>  >> Would really appreciate some feedback.
>  >>
>  >> Kind regards,
>  >>
>  >> Stephan
>  >>
>  >>
>  >>
>  >>
>  >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman <_Reza.Rahman at oracle.com_
> <mailto:Reza.Rahman at oracle.com>
>  >> <mailto:_Reza.Rahman at oracle.com_ <mailto:Reza.Rahman at 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 at knitelius.com_
> <mailto:stephan at knitelius.com><mailto:_stephan at knitelius.com_
> <mailto:stephan at knitelius.com>>
>  >>>
>  >>>
>  >>>    _______________________________________________
>  >>>    cdi-dev mailing list
>  >>> _cdi-dev at lists.jboss.org_
> <mailto:cdi-dev at lists.jboss.org><mailto:_cdi-dev at lists.jboss.org_
> <mailto:cdi-dev at 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 at lists.jboss.org_
> <mailto:cdi-dev at lists.jboss.org><mailto:_cdi-dev at lists.jboss.org_
> <mailto:cdi-dev at 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 at lists.jboss.org_ <mailto:cdi-dev at 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 at lists.jboss.org_ <mailto:cdi-dev at 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 at lists.jboss.org_ <mailto:cdi-dev at lists.jboss.org>_
> __https://lists.jboss.org/mailman/listinfo/cdi-dev_
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2
> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU_______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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


More information about the cdi-dev mailing list