[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