because the barrier we setup in getPage() already takes care of the sync around the page
(without a real large sync blok)
So if we want to make one place. Then the current barrier in getPage() is the one that should be there
and the rest can maybe be removed.
What we then do miss is this: In Page A there is a reference to Page B and page a does have a barrier but
page B ofcourse not. So if a request comes in for A and that request touched B through A then
another request for B doesn't know that. And currently that is what RequestTarget sync around session
also resolves. (and maybe the Session object itself. But that one isn't really threadsafe all the way anyway currently)
What we could do is don't make the barrier on Page id's but just on page (any) access in that place.
If we have that then any page request will be blocked at that place (as it would be now in RequestTarget.requestAndRespond )
johan
On 9/8/06, SourceForge.net <[EMAIL PROTECTED]> wrote:
Bugs item #1554508, was opened at 2006-09-08 06:33
Message generated for change (Comment added) made by eelco12
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684975&aid=1554508&group_id=119783
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Eelco Hillenius (eelco12)
Assigned to: Johan Compagner (joco01)
Summary: Infinite Loop on Session.getPage
Initial Comment:
From thread:
http://www.nabble.com/Infinite-Loop-on-Session.getPage%28%29-tf2233107.html
Here's a trace of what happens that causes the problem :
During the RESOLVE_TARGET step of RequestCycle, the
target is trying to
be resolved using the
DefaultRequestTargetResolverStrategy, which first
inside the resolveRenderedPage() method uses
Session.getPage() to get
the page,(which adds it to the usedPages map,a hidden
side-effect
imho),and then calls resolveListenerInterfaceTarget()
where it retrieves
the Component for the path and calls
isVisibleInHierarchy() on it. This
method throws an exception in my application, which is
caught back in
the RequestCycle. Now, the target didn't have a chance
to be added to
requestTargets, but the page has been added to the
usedPages. In the
detach phase, the requestTargets are detached one by
one, which in this
case is only the exception page generated. So when i
push back and click
on another link with the same page id, it'll fall into
the loop
mentioned, cause the thread hasn't been cleared. I
guess this somehow
means a problem with the usedPages map, where it should
be cleared on an
exception.
----------------------------------------------------------------------
>Comment By: Eelco Hillenius (eelco12)
Date: 2006-09-08 07:00
Message:
Logged In: YES
user_id=820266
Ultimately, the problem comes down to synchronization being
scattered over various places. Can we find a way to
synchronize all we need from one place without loosing the
efficiency we have now?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684975&aid=1554508&group_id=119783
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
