Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (nike.apache.org: domain of vojtech.zavrel@gmail.com
 designates 209.85.220.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:date:x-google-sender-auth:message-id:subject
         :from:to:content-type;
        b=pQg6W5jXNDmVmLJvYKbwwMVkmrosQ0gMHi1RfNwIAtkQrm5NxUMpn1gyEwm8Z6dcN1
         K2VOG0DfSQXEPv27coqpy3O86fUrI1JSNMJ94wTkP2vpsVULsd1eN9EcH8UGeV7MUHHY
         z3LRtuVK1FrHsBtA9WOjBibc9lu3FTVhDBCc8=
MIME-Version: 1.0
Sender: vojtech.zavrel@gmail.com
Date: Thu, 20 Aug 2009 10:51:15 +0200
Message-ID: <73721da20908200151g2ed4aec7t175e23b4dcbded1d@mail.gmail.com>
Subject: Concurrent requests and Orchestra
From: Vojtech Zavrel <vojtech.zavrel@aura.cz>
To: users@myfaces.apache.org
Content-Type: multipart/alternative; boundary=0015175cadb0b9db2404718eda4f

--0015175cadb0b9db2404718eda4f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

 Hi,
 we have a problem with concurrent request using combination Orchestra +
Spring + Trinidad. The application uses more than one window per session, so
we have migrated all our beans to orchestra's conversation scope using
conversation.manual.
We have a progress bar which is poling AJAX request during the main request
is being done. Once user is waiting to the main request, there are partial
requests each five seconds using Trinidad Javascript API. To be able handle
more requests the partial request goes in another frame with same
conversationContext.
Both partial and full request are accessing to the same bean. And this is
the problem because there is there is ReentrantLock used not to be able to
access to FacesContex from different thread. So that means, that we are not
able to access to the progressbar model and the partial request is locked
till the full request is finished. But I haven't understood why there is
this concurrent limitatins because they aren't in other scopes.

This is the comment from the source code:

// Fetch a context for this request if one already exists, and lock it
72 // so that concurrent requests that affect this context block until
73 // this request is complete. Not doing so can cause races for resources
74 // within the current context, such as beans or PersistenceContexts.

But what kind of races and why there are not same problems using other
scopes. Can anybody explain me the reasons please? Is there any possibility
how to make a workaround?

Thanks


Daemon Thread [http-8080-1] (Suspended)
Object.wait(long) line: not available [native method] [local variables
unavailable]
_ReentrantLock.lockInterruptibly() line: 80
ConversationContext.lockInterruptablyForCurrentThread() line: 475
ContextLockRequestHandler.init(FacesContext) line: 96
OrchestraFacesContextFactory$1.<init>(OrchestraFacesContextFactory,
FacesContext, boolean, LinkedList, FacesContext) line: 119
OrchestraFacesContextFactory.getFacesContext(Object, Object, Object,
Lifecycle) line: 100
RequestParameterFacesContextFactory.getFacesContext(Object, Object, Object,
Lifecycle) line: 92
FacesContextFactoryImpl.getFacesContext(Object, Object, Object, Lifecycle)
line: 64
FacesServlet.service(ServletRequest, ServletResponse) line: 260
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse)
line: 290
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206
TrinidadFilterImpl._invokeDoFilter(ServletRequest, ServletResponse,
FilterChain) line: 238
TrinidadFilterImpl._doFilterImpl(ServletRequest, ServletResponse,
FilterChain) line: 195
TrinidadFilterImpl.doFilter(ServletRequest, ServletResponse, FilterChain)
line: 138
TrinidadFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line:
92
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse)
line: 235
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206
LicenseFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line:
123
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse)
line: 235
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206
ResponseHeaderFilter.doFilter(ServletRequest, ServletResponse, FilterChain)
line: 54
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse)
line: 235
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206
SessionTimeoutFilter.doFilter(ServletRequest, ServletResponse, FilterChain)
line: 116
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse)
line: 235
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206
StandardWrapperValve.invoke(Request, Response) line: 233
StandardContextValve.invoke(Request, Response) line: 175
StandardHostValve.invoke(Request, Response) line: 128
ErrorReportValve.invoke(Request, Response) line: 102
StandardEngineValve.invoke(Request, Response) line: 109
CoyoteAdapter.service(Request, Response) line: 263
Http11Processor.process(Socket) line: 844
Http11Protocol$Http11ConnectionHandler.process(Socket) line: 584
JIoEndpoint$Worker.run() line: 447
Thread.run() line: 619

--0015175cadb0b9db2404718eda4f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


<div class=3D"moz-text-html" lang=3D"x-central-euro">


<font size=3D"-1"><font face=3D"Helvetica, Arial, sans-serif">Hi, <br>
=C2=A0we have a problem with concurrent request using combination Orchestra
+ Spring + Trinidad. The application uses more than one window per
session, so we have migrated all our beans to orchestra&#39;s conversation
scope using conversation.manual. <br>
We have a progress bar which is poling AJAX request during the main
request is being done. Once user is waiting to the main request, there
are partial requests each five seconds using Trinidad Javascript API.
To be able handle more requests the partial request goes in another
frame with same conversationContext. <br>
Both partial and full request are accessing to the same bean. And this
is the problem because there is there is ReentrantLock used not to be
able to access to FacesContex from different thread. </font></font><font si=
ze=3D"-1"><font face=3D"Helvetica, Arial, sans-serif">So that
means, that we are not able to access to the progressbar model and the
partial request is locked till the full request is finished.</font></font><=
font size=3D"-1"><font face=3D"Helvetica, Arial, sans-serif"> But I haven&#=
39;t
understood why there is this concurrent limitatins because they aren&#39;t
in other scopes.<br>
<br>
This is the comment from the source code:<br>
=C2=A0<br>
// Fetch a context for this request if one already exists, and lock it<br>
72 // so that concurrent requests that affect this context block until<br>
73 // this request is complete. Not doing so can cause races for
resources<br>
74 // within the current context, such as beans or PersistenceContexts.<br>
<br>
But what kind of races and why there are not same problems using other
scopes. </font></font><font size=3D"-1"><font face=3D"Helvetica, Arial, san=
s-serif">Can anybody explain me the reasons
please? Is there any possibility how to make a workaround?<br>
<br>
Thanks <br>
<br>
</font></font><font size=3D"-1"><font face=3D"Helvetica, Arial, sans-serif"=
><br>
Daemon Thread [http-8080-1] (Suspended) <br>
Object.wait(long) line: not available [native method] [local variables
unavailable] <br>
_ReentrantLock.lockInterruptibly() line: 80 <br>
ConversationContext.lockInterruptablyForCurrentThread() line: 475 <br>
ContextLockRequestHandler.init(FacesContext) line: 96 <br>
OrchestraFacesContextFactory$1.&lt;init&gt;(OrchestraFacesContextFactory,
FacesContext, boolean, LinkedList, FacesContext) line: 119 <br>
OrchestraFacesContextFactory.getFacesContext(Object, Object, Object,
Lifecycle) line: 100 <br>
RequestParameterFacesContextFactory.getFacesContext(Object, Object,
Object, Lifecycle) line: 92 <br>
FacesContextFactoryImpl.getFacesContext(Object, Object, Object,
Lifecycle) line: 64 <br>
FacesServlet.service(ServletRequest, ServletResponse) line: 260 <br>
ApplicationFilterChain.internalDoFilter(ServletRequest,
ServletResponse) line: 290 <br>
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line:
206 <br>
TrinidadFilterImpl._invokeDoFilter(ServletRequest, ServletResponse,
FilterChain) line: 238 <br>
TrinidadFilterImpl._doFilterImpl(ServletRequest, ServletResponse,
FilterChain) line: 195 <br>
TrinidadFilterImpl.doFilter(ServletRequest, ServletResponse,
FilterChain) line: 138 <br>
TrinidadFilter.doFilter(ServletRequest, ServletResponse, FilterChain)
line: 92 <br>
ApplicationFilterChain.internalDoFilter(ServletRequest,
ServletResponse) line: 235 <br>
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line:
206 <br>
LicenseFilter.doFilter(ServletRequest, ServletResponse, FilterChain)
line: 123 <br>
ApplicationFilterChain.internalDoFilter(ServletRequest,
ServletResponse) line: 235 <br>
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line:
206 <br>
ResponseHeaderFilter.doFilter(ServletRequest, ServletResponse,
FilterChain) line: 54 <br>
ApplicationFilterChain.internalDoFilter(ServletRequest,
ServletResponse) line: 235 <br>
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line:
206 <br>
SessionTimeoutFilter.doFilter(ServletRequest, ServletResponse,
FilterChain) line: 116 <br>
ApplicationFilterChain.internalDoFilter(ServletRequest,
ServletResponse) line: 235 <br>
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line:
206 <br>
StandardWrapperValve.invoke(Request, Response) line: 233 <br>
StandardContextValve.invoke(Request, Response) line: 175 <br>
StandardHostValve.invoke(Request, Response) line: 128 <br>
ErrorReportValve.invoke(Request, Response) line: 102 <br>
StandardEngineValve.invoke(Request, Response) line: 109 <br>
CoyoteAdapter.service(Request, Response) line: 263 <br>
Http11Processor.process(Socket) line: 844 <br>
Http11Protocol$Http11ConnectionHandler.process(Socket) line: 584 <br>
JIoEndpoint$Worker.run() line: 447 <br>
Thread.run() line: 619 <br>
</font></font>
</div>

--0015175cadb0b9db2404718eda4f--