[cdi-dev] Concurrency Control

Fri Feb 26 11:39:07 EST 2016

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, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
>
> 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
>         cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
>
> 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 <reza_rahman at lycos.com>
> Subject: Re: [cdi-dev] Concurrency Control
> To: Emily Jiang <EMIJIANG at uk.ibm.com>
> Cc: cdi-dev at lists.jboss.org
> Message-ID: <7313A4E6-24FA-4427-964A-BADF7FBE4FB8 at lycos.com>
> 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 <EMIJIANG at uk.ibm.com> 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: 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> 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
> > Lotus Notes: Emily Jiang/UK/IBM at IBMGB
> >
> >
> >
> >
> > From:        Stephan Knitelius <stephan at knitelius.com>
> > To:        Reza Rahman <reza_rahman at lycos.com>, Martin Kouba <
> mkouba at redhat.com>,
> > Cc:        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
> >
> >
> >
> > 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> 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> 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>> 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>
> > >>>
> > >>>
> > >>>    _______________________________________________
> > >>>    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.
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> > > _______________________________________________
> > > 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._______________________________________________
> > 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.
> >
> > 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
> 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.
>
> End of cdi-dev Digest, Vol 63, Issue 36
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/8a4b5cca/attachment-0001.html 