Ok, I'll take a look at whether I can follow this this weekend. That
must be the worst code ever though, if it's so unobvious. And why do
we still have that maxPageVersions application parameter, and the
maxversions member in the pageversion member? The whole way this works
sounds like one big fat hack to me; it probably is to get around the
initial limitations without breaking the API, is that correct?

Eelco


On 6/8/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> no it is true for page versions
> there will be a Access object created for every page version
> that will be pushed on the access stack (in the pagemap)
> that access object has 2 variables: pageid and versionnumber
>  that makes it unique
>
> and you are looking at the wrong thing that Settings.maxPageVersions doesn't
> do much
> its the:
> public LeastRecentlyAccessedEvictionStrategy(int
> maxVersions) (IPageMapEvictionStrategy)
>
> that one evicts such a access objects from the pagemap.
> and if it events an Access object with pageid 7 and version 2
> it will delete that version from the changelist of the versionmanger for
> that page
> and if that is the last one the complete page is removed. If not then there
> is just one version less for that page.
>
> So no in wicket 1.2 we don't build up a page over and over again. There is
> really only 5 or 7 (i see 5 is now the default)
> page/pageversions alive at one time (5 access objects)
>
> the problem was if i remember correctly pure ajax pages. (and i don't see at
> the moment how that did go wrong in 1.2)
>
>
> johan
>
>
>
>
> On 6/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > I don't think that is true for page *versions*, which is also used
> > when you use component replacement, ajax or not.
> >
> > A quick look reveals that Settings#maxPageVersions is still max int,
> > and in 1.2, Page has
> >
> >         protected IPageVersionManager newVersionManager()
> >         {
> >                 final IPageSettings settings =
> > getSession().getApplication().getPageSettings();
> >                 return new UndoPageVersionManager(this,
> settings.getMaxPageVersions());
> >         }
> >
> > Then, UndoPageVersionManager has
> >
> >                 // If stack is overfull, remove oldest entry
> >                 if (getVersions() > maxVersions)
> >                 {
> >                         expireOldestVersion();
> >                 }
> >
> > in method endVersion. So unless I miss something in the larger
> > picture, it looks to me that whenever you do component replacement on
> > a page, it just keeps building up versions until max int is reached.
> > And this is exactly what I've been objecting to in the past, and I
> > still think max int is a crazy (dangerous) default. But please do
> > enlighten me if I'm wrong. And maybe this time we can either clear
> > this up or fix it for once and for all.
> >
> > Eelco
> >
> >
> > On 6/8/07, Johan Compagner <[EMAIL PROTECTED] > wrote:
> > > that growing of a page constantly is only a problem when you use one
> page
> > > and through ajax request you constantly change that single page.
> > >
> > > if not then the page versions will be removed because there can only be
> 7
> > > (pages + page versions) by default
> > >
> > > johan
> > >
> > >
> > >
> > > On 6/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > We're using 1.2.6.  Is the 2nd level cache available prior to 1.3?
> > > >
> > > > It's only in 1.3 I'm afraid.
> > > >
> > > > > As for page complexity, we commonly have a reasonably robust
> repeater
> > > > > or list view on each page (though without too many rows) along with
> a
> > > > > form or two.
> > > > >
> > > > > I'm concerned about models because as I do work on a given page I
> see
> > > > > the older page maps change in size.  I.e. I have p0=30K, p1=33K --
> > > > > then I do something substantial on p2 and see the size of p0 & p1
> each
> > > > > increase by 11K.
> > > >
> > > > One known issue with the old sessionstore is that deltas of a page are
> > > > stored in the page itself. This will result in the page keep on
> > > > growing. We've had lots of discussion about this, which resulted in
> > > > the default session store implementation of 1.3 now storing the whole
> > > > page for each version to second level cache (temp dir) instead.
> > > >
> > > > I'm not sure how to fix this for 1.2 tbh. To limit how far those
> > > > versions can grow, you can set maxVersions in UndoPageVersionManager,
> > > > which in 1.2 is a setting somewhere (sorry don't know from the top of
> > > > my head).
> > > >
> > > > Eelco
> > > >
> > > >
> > >
> -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by DB2 Express
> > > > Download DB2 Express C - the FREE version of DB2 express and take
> > > > control of your XML. No limits. Just data. Click to get it now.
> > > > http://sourceforge.net/powerbar/db2/
> > > > _______________________________________________
> > > > Wicket-user mailing list
> > > > Wicket-user@lists.sourceforge.net
> > > >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > > >
> > >
> > >
> > >
> -------------------------------------------------------------------------
> > > This SF.net email is sponsored by DB2 Express
> > > Download DB2 Express C - the FREE version of DB2 express and take
> > > control of your XML. No limits. Just data. Click to get it now.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > Wicket-user mailing list
> > > Wicket-user@lists.sourceforge.net
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > >
> > >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to