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@uk.ibm.com

> Lotus Notes: Emily Jiang/UK/IBM@IBMGB

>

>

>

>

> From: Reza Rahman <reza_rahman@lycos.com>

> To: Emily Jiang/UK/IBM@IBMGB,

> Cc: cdi-dev@lists.jboss.org

> Date: 25/02/2016 23:01

> Subject: Re: [cdi-dev] Concurrency Control

> Sent by: cdi-dev-bounces@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@uk.ibm.com_

> <
mailto:EMIJIANG@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@uk.ibm.com_ <
mailto:emijiang@uk.ibm.com
>

> Lotus Notes: Emily Jiang/UK/IBM@IBMGB

>

>

>

>

> From: Stephan Knitelius <_stephan@knitelius.com_

> <
mailto:stephan@knitelius.com
>>

> To: Reza Rahman <_reza_rahman@lycos.com_

> <
mailto:reza_rahman@lycos.com
>>,
Martin Kouba <_mkouba@redhat.com_

> <
mailto:mkouba@redhat.com
>>,

> Cc: _cdi-dev@lists.jboss.org_ <
mailto:cdi-dev@lists.jboss.org
>

> Date: 25/02/2016 20:26

> Subject: Re: [cdi-dev] Concurrency Control

> Sent by: _cdi-dev-bounces@lists.jboss.org_

> <
mailto:cdi-dev-bounces@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@lycos.com_

> <
mailto:reza_rahman@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@redhat.com_

> <
mailto:mkouba@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@oracle.com_

> <
mailto:Reza.Rahman@oracle.com
>

>  >> <
mailto:_Reza.Rahman@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@knitelius.com_

> <
mailto:stephan@knitelius.com
><
mailto:_stephan@knitelius.com_

> <
mailto:stephan@knitelius.com
>>

>  >>>

>  >>>

>  >>>    _______________________________________________

>  >>>    cdi-dev mailing list

>  >>> _cdi-dev@lists.jboss.org_

> <
mailto:cdi-dev@lists.jboss.org
><
mailto:_cdi-dev@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@lists.jboss.org_

> <
mailto:cdi-dev@lists.jboss.org
><
mailto:_cdi-dev@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@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.

>  >

>  > --

>  > Martin Kouba

>  > Software Engineer

>  > Red Hat, Czech Republic

>  > _______________________________________________

>  > cdi-dev mailing list

>  > _cdi-dev@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@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.

>

> 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@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@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@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.