<div dir="ltr">I just want to bring this to everyone attention one more time.<div><br></div><div>The conversation scope concurrency control mechanism seems to be a frequent point of pain in many projects. </div><div><br></div><div>Especially when working with browser triggered asynchronous requests, you can not rely on client-sided request synchronization. </div><div><span style="line-height:1.5">Weld, unlike OWB, grants a 1 second timeout prior to throwing a </span><span style="line-height:1.5">(the specified)</span><span style="line-height:1.5"> BusyConversationException mitigating the effect a bit.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">This is a rather strict un-</span>configurable<span style="line-height:1.5"> type of CC. Also its </span>completely<span style="line-height:1.5"> out of </span>alignment<span style="line-height:1.5"> with the other build-in scopes, offering no CC what so ever.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">In the cases of Session- and Application-Scope, thread handling is left </span>entirely<span style="line-height:1.5"> to the developer, even so they are just as </span>vulnerable <span style="line-height:1.5">in AJAX </span>environments<span style="line-height:1.5">.</span><br></div><div><br></div><div>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). </div><div><br></div><div>Would really appreciate some feedback.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Stephan </div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5"><br></span></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 22 Feb 2016 at 23:10 Reza Rahman <<a href="mailto:Reza.Rahman@oracle.com">Reza.Rahman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>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.</div></div><div bgcolor="#FFFFFF" text="#000000"><div><br>
<br>
On 2/19/2016 5:27 AM, Stephan Knitelius wrote:<br>
</div></div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>CDI Spec:</div>
<div><span>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</span><code>javax.enterprise.context.BusyConversationException</code><span>.</span><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>It would be helpful if a common configurable concurrency
mechanism (EJB Singleton style locking?) could be established
for all normal scopes. </div>
<div><br>
</div>
<div>What are your thoughts on this?</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Stephan</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div><br>
______________________________________<br>
<b>Stephan Knitelius</b><br>
Alteburger Str. 274<br>
50968 Köln / Cologne<br>
Deutschland / Germany<br>
<a href="mailto:stephan@knitelius.com" target="_blank">stephan@knitelius.com</a></div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><pre>_______________________________________________
cdi-dev mailing list
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</blockquote></div>