<font size=2 face="sans-serif">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. </font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Many thanks,<br>
Emily<br>
===========================<br>
Emily Jiang<br>
WebSphere Application Server, CDI Development Lead</font>
<br><font size=2 face="sans-serif"> <br>
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN<br>
Phone: +44 (0)1962 816278 Internal: 246278<br>
<br>
Email: emijiang@uk.ibm.com <br>
Lotus Notes: Emily Jiang/UK/IBM@IBMGB<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Stephan Knitelius <stephan@knitelius.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Reza Rahman <reza_rahman@lycos.com>,
Martin Kouba <mkouba@redhat.com>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">cdi-dev@lists.jboss.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">25/02/2016 20:26</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [cdi-dev]
Concurrency Control</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">cdi-dev-bounces@lists.jboss.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>Hi Martin,</font>
<br>
<br><font size=3>yes this particular issue is about concurrent access control.
You are right in pointing out that the lock should be applied </font>
<br><font size=3>to the whole been and only override-able on
a per method basis (similar to EJB Singleton style locking). </font>
<br>
<br><font size=3>Regarding conversation context, its fair enough to point-out
that weld allows for configure the conversation lock timeout.</font>
<br><font size=3>However this is only true for Weld, this should really
be made part of the specification.</font>
<br>
<br><font size=3>Even if we were to specify a standard way to configure
conversation locked timeouts in the CDI specification, it would</font>
<br><font size=3>still make the conversation scope the odd one out of the
lot. Hence it would be more sensible to design a </font>
<br><font size=3>common way to handle concurrent access.</font>
<br>
<br><font size=3>Also I would argue that you cannot implement a common
concurrent access control via interceptors, </font>
<br><font size=3>since the container will preempt any interceptor based
attempt for conversation scoped beans.</font>
<br>
<br><font size=3>As Reza pointed out Oracle has no intend to reopen "Concurrency
Utilities for Java EE" at this time and is not</font>
<br><font size=3>willing to hand it over to anyone else. The same seems
to be true for JTA.</font>
<br>
<br><font size=3>Stephan</font>
<br>
<br>
<br>
<br><font size=3> </font>
<br>
<br>
<br>
<br>
<br>
<br>
<br><font size=3> </font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br><font size=3>On Thu, 25 Feb 2016 at 15:50 Reza Rahman <</font><a href=mailto:reza_rahman@lycos.com><font size=3 color=blue><u>reza_rahman@lycos.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>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.<br>
<br>
> On Feb 25, 2016, at 9:13 AM, Martin Kouba <</font><a href=mailto:mkouba@redhat.com target=_blank><font size=3 color=blue><u>mkouba@redhat.com</u></font></a><font size=3>>
wrote:<br>
><br>
> Hi Stephan,<br>
><br>
> I like the idea of CDI interceptor solution you're proposing in your<br>
> blogpost [1]. However, concurrency is a difficult topic. First of
all,<br>
> this only solves concurrent access to the bean instance (i.e.<br>
> method-level locking) - the bean state is always up to the user. Also<br>
> I'm not so sure it's a good idea to only apply @Lock at the method
level<br>
> (some methods are guarded some not - AFAIK EJB does not allow this
either).<br>
><br>
> I agree that conversation concurrentAccessTimeout in Weld should be<br>
> configurable. In fact, it should be possible to change this timeout
even<br>
> now using Weld API and org.jboss.weld.context.ConversationContext.
But<br>
> it should be definitely more straightforward [2].<br>
><br>
> To sum it up - I wouldn't add concurrency control to the spec provided<br>
> it's implementable using interceptors. This is a similar situation
as to<br>
> javax.transaction.Transactional and JTA. The best place to specify
this<br>
> is IMHO "Concurrency Utilities for Java EE".<br>
><br>
> Martin<br>
><br>
> [1]<br>
> </font><a href="http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/" target=_blank><font size=3 color=blue><u>http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/</u></font></a><font size=3><br>
><br>
> [2]<br>
> </font><a href="https://issues.jboss.org/browse/WELD-2113" target=_blank><font size=3 color=blue><u>https://issues.jboss.org/browse/WELD-2113</u></font></a><font size=3><br>
><br>
> Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a):<br>
>> I just want to bring this to everyone attention one more time.<br>
>><br>
>> The conversation scope concurrency control mechanism seems to
be a<br>
>> frequent point of pain in many projects.<br>
>><br>
>> Especially when working with browser triggered asynchronous requests,<br>
>> you can not rely on client-sided request synchronization.<br>
>> Weld, unlike OWB, grants a 1 second timeout prior to throwing
a (the<br>
>> specified) BusyConversationException mitigating the effect a bit.<br>
>><br>
>> This is a rather strict un-configurable type of CC. Also its<br>
>> completely out of alignment with the other build-in scopes, offering
no<br>
>> CC what so ever.<br>
>><br>
>> In the cases of Session- and Application-Scope, thread handling
is left<br>
>> entirely to the developer, even so they are just as vulnerable
in AJAX<br>
>> environments.<br>
>><br>
>> We should really consider introducing a common configurable mechanism,<br>
>> that is aligned across all scopes (obviously accounting for backwards<br>
>> compatibility in the case of conversation scope).<br>
>><br>
>> Would really appreciate some feedback.<br>
>><br>
>> Kind regards,<br>
>><br>
>> Stephan<br>
>><br>
>><br>
>><br>
>><br>
>> On Mon, 22 Feb 2016 at 23:10 Reza Rahman <</font><a href=mailto:Reza.Rahman@oracle.com target=_blank><font size=3 color=blue><u>Reza.Rahman@oracle.com</u></font></a><font size=3><br>
>> <mailto:</font><a href=mailto:Reza.Rahman@oracle.com target=_blank><font size=3 color=blue><u>Reza.Rahman@oracle.com</u></font></a><font size=3>>>
wrote:<br>
>><br>
>> We've discussed this issue before. I definitely still
think @Lock<br>
>> belongs in a modular CDI specification. It would
be highly useful to<br>
>> both @Singleton and @ApplicationScoped. Today if
I need to use<br>
>> declarative concurrency control for a shared component
I am<br>
>> essentially forced to use EJB singleton - which shouldn't
be the<br>
>> case and perhaps should not have been the case past
Java EE 6.<br>
>><br>
>><br>
>>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote:<br>
>>> Hi all,<br>
>>><br>
>>> CDI spec does not define a common concurrency
control mechanism.<br>
>>> The time any type of concurrency control is mentioned
is in<br>
>>> conjunction with EJB and a rather restrictive
one for conversation<br>
>>> context.<br>
>>><br>
>>> CDI Spec:<br>
>>> The container ensures that a long-running conversation
may be<br>
>>> associated with at most one request at a time,
by blocking or<br>
>>> rejecting concurrent requests. If the container
rejects a request,<br>
>>> it must associate the request with a new transient
conversation<br>
>>> and throw an exception of<br>
>>> type|javax.enterprise.context.BusyConversationException|.<br>
>>><br>
>>><br>
>>> It would be helpful if a common configurable
concurrency mechanism<br>
>>> (EJB Singleton style locking?) could be established
for all normal<br>
>>> scopes.<br>
>>><br>
>>> What are your thoughts on this?<br>
>>><br>
>>> Regards,<br>
>>><br>
>>> Stephan<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> ______________________________________<br>
>>> *Stephan Knitelius*<br>
>>> Alteburger Str. 274<br>
>>> 50968 Köln / Cologne<br>
>>> Deutschland / Germany<br>
>>> </font><a href=mailto:stephan@knitelius.com target=_blank><font size=3 color=blue><u>stephan@knitelius.com</u></font></a><font size=3>
<mailto:</font><a href=mailto:stephan@knitelius.com target=_blank><font size=3 color=blue><u>stephan@knitelius.com</u></font></a><font size=3>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> cdi-dev mailing list<br>
>>> </font><a href="mailto:cdi-dev@lists.jboss.org" target=_blank><font size=3 color=blue><u>cdi-dev@lists.jboss.org</u></font></a><font size=3>
<mailto:</font><a href="mailto:cdi-dev@lists.jboss.org" target=_blank><font size=3 color=blue><u>cdi-dev@lists.jboss.org</u></font></a><font size=3>><br>
>>> </font><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target=_blank><font size=3 color=blue><u>https://lists.jboss.org/mailman/listinfo/cdi-dev</u></font></a><font size=3><br>
>>><br>
>>> Note that for all code provided on this list,
the provider licenses the code under the Apache License, Version 2 (</font><a href="http://www.apache.org/licenses/LICENSE-2.0.html" target=_blank><font size=3 color=blue><u>http://www.apache.org/licenses/LICENSE-2.0.html</u></font></a><font size=3>).
For all other ideas provided on this list, the provider waives all patent
and other intellectual property rights inherent in such information.<br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> </font><a href="mailto:cdi-dev@lists.jboss.org" target=_blank><font size=3 color=blue><u>cdi-dev@lists.jboss.org</u></font></a><font size=3>
<mailto:</font><a href="mailto:cdi-dev@lists.jboss.org" target=_blank><font size=3 color=blue><u>cdi-dev@lists.jboss.org</u></font></a><font size=3>><br>
>> </font><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target=_blank><font size=3 color=blue><u>https://lists.jboss.org/mailman/listinfo/cdi-dev</u></font></a><font size=3><br>
>><br>
>> Note that for all code provided on this list, the
provider licenses<br>
>> the code under the Apache License, Version 2<br>
>> (</font><a href="http://www.apache.org/licenses/LICENSE-2.0.html" target=_blank><font size=3 color=blue><u>http://www.apache.org/licenses/LICENSE-2.0.html</u></font></a><font size=3>).
For all other<br>
>> ideas provided on this list, the provider waives
all patent and<br>
>> other intellectual property rights inherent in such
information.<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> </font><a href="mailto:cdi-dev@lists.jboss.org" target=_blank><font size=3 color=blue><u>cdi-dev@lists.jboss.org</u></font></a><font size=3><br>
>> </font><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target=_blank><font size=3 color=blue><u>https://lists.jboss.org/mailman/listinfo/cdi-dev</u></font></a><font size=3><br>
>><br>
>> Note that for all code provided on this list, the provider licenses
the code under the Apache License, Version 2 (</font><a href="http://www.apache.org/licenses/LICENSE-2.0.html" target=_blank><font size=3 color=blue><u>http://www.apache.org/licenses/LICENSE-2.0.html</u></font></a><font size=3>).
For all other ideas provided on this list, the provider waives all patent
and other intellectual property rights inherent in such information.<br>
><br>
> --<br>
> Martin Kouba<br>
> Software Engineer<br>
> Red Hat, Czech Republic<br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> </font><a href="mailto:cdi-dev@lists.jboss.org" target=_blank><font size=3 color=blue><u>cdi-dev@lists.jboss.org</u></font></a><font size=3><br>
> </font><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target=_blank><font size=3 color=blue><u>https://lists.jboss.org/mailman/listinfo/cdi-dev</u></font></a><font size=3><br>
><br>
> Note that for all code provided on this list, the provider licenses
the code under the Apache License, Version 2 (</font><a href="http://www.apache.org/licenses/LICENSE-2.0.html" target=_blank><font size=3 color=blue><u>http://www.apache.org/licenses/LICENSE-2.0.html</u></font></a><font size=3>).
For all other ideas provided on this list, the provider waives all patent
and other intellectual property rights inherent in such information.</font><tt><font size=2>_______________________________________________<br>
cdi-dev mailing list<br>
cdi-dev@lists.jboss.org<br>
</font></tt><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev"><tt><font size=2>https://lists.jboss.org/mailman/listinfo/cdi-dev</font></tt></a><tt><font size=2><br>
<br>
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (</font></tt><a href="http://www.apache.org/licenses/LICENSE-2.0.html"><tt><font size=2>http://www.apache.org/licenses/LICENSE-2.0.html</font></tt></a><tt><font size=2>).
For all other ideas provided on this list, the provider waives all patent
and other intellectual property rights inherent in such information.</font></tt>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>