[
https://issues.apache.org/jira/browse/WICKET-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923112#action_12923112
]
Pedro Santos commented on WICKET-3108:
--------------------------------------
Why don't prevent the removed pagemap from get into the dirty list at first
place? There is no need to codify an second removal logic at the removePageMap
method. It looks like we are fixing an error rather than prevent it.
> Problems with page maps stored in session
> -----------------------------------------
>
> Key: WICKET-3108
> URL: https://issues.apache.org/jira/browse/WICKET-3108
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.12
> Reporter: Jeremy Thomerson
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.13
>
> Attachments: pagemapstuff-quickstart.tar.gz, patch.txt, patch.txt,
> problem-1.patch, problem-2.patch, problem-3.patch
>
>
> A client engaged me to assist in fixing multiple problems they found while
> writing a custom page map eviction strategy for page maps that have not been
> accessed in a while. Digging into the first problem revealed a few others.
> I'd like someone who is more familiar than me with the session and page map
> stuff to review this before I commit it. The quick start attached
> demonstrates the problems. I have yet to write test cases that can be added
> to the suite to replicate these issues.
> PROBLEM 1:
> If you call IPageMap.remove(), the page map is not actually removed because
> it's in the dirty objects list, which means that it gets set back on the
> session in the requestDetached() method. The quickstart demonstrates this in
> a link for ease of demonstration, but in reality, it applies even if someone
> is doing custom page map eviction in their request cycle somewhere.
> PROBLEM 2:
> It seems to be a safe assumption that every page map that is used in the
> session should also be in usedPageMaps, and that this map should always be
> exactly in sync with what's actually in your session (as attributes). Right
> now, they are not in sync. First, the default page map was not added to
> usedPageMaps in the dirtyPageMap(IPageMap) method. Second, when page maps
> are created, they are not dirtied (which means they are not in the
> usedPageMaps collection), although they are set as attributes on the session
> immediately. This causes a problem in the newPageMap(String) method with
> actually adhering to the max number you set.
> PROBLEM 3:
> If you have a bunch of popup links on a page, they can create more page maps
> than are allowed, and the number of page maps stored in the session grows
> beyond the limit of what you've specified. The real unanswered question I
> have is this: must we really create the page map when the link is first
> rendered? Or could we wait until it is clicked?
> NOTE: the fix for problems 2 and 3 relies on the fix for problem 1 being
> committed, because the call to pm.remove() in newPageMap(IPageMap) will not
> work without the fix for problem 1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
