> And if you where on version 10 and you roll backed to 6 you will never
> be able to get 7 back.
This is how it should be (and was) in the first place. I applied a
little patch yesterday that actually deletes those higher version
(together with a patch that only writes a version when that version
wasn't written before yet).
no see the reply of martijn (and me again) this is a bug in the current
system
that was fixed by the current implementation!
Or all undo objects should also be able to redo..
What do you mean? If a certain undo shouldn't be done, it shouldn't be
recorded in the first place, right?
See previous point
IF you do a refresh of the previous page and then go back to the newer page
(forward in the browser)
then you should be able to redo it. Currently this is also not a problem
because that version
can be read from disk again (if you don't delete them already which shouldnt
be done!)
When we rollback, we should invalidate newer versions of the page
relative to the version that is rollbacked to anyway. I think this was
always the idea, and was how the page version manager was implemented.
No we shouldn't do it.
Maybe a browser will be able to go forward again even in other situations
then
the current one. ALL pages should be reachable so we are bullet proof in all
situations.
Partially it is just fixing something that is broken now. We could
decide to write full versions rather then one full page and a series
of changes. However, as this is something we do for every request
(though we might do it async, but still it's for every request), it
makes sense to optimize as best as we can. From testing on my machine,
a typical save of a page with one or two versions costs between 5 - 20
miliseconds (which obviously increases currently as more versions get
added to the page, with my system here easily up 50 miliseconds are 10
clicks, and it is also on a warmed up system, where the introspection
caches are filled properly; the first saves are up to 500
miliseconds!). This would be 1 - 2 miliseconds for just writing the
changes. On a system with heavy load, I believe this can make quite
the difference. Note that it's not only processing time, but also
space it takes in the FS (minor) and time it needs the filesystem.
> And do remember that most clustering situations do exactly the same but
then
> for the complete session
> We only for changed pages!
The fact that other solutions are not optimized doesn't mean we don't have
to :
i get a dejavu discussion from the wicket irc list from yesterday
Dont try to optimize upfront only when there is really a problem..
And there is no problem currently i don't believe it until i see it.
I like to see it with my own eyes as a hotspot in yourkit..
But i agree with you that constantly saving a page with full version info is
a waste.
But to make the system so much more difficult to try to gain some speed. is
in my eyes a waste.
So still what i think we should do is set the max page versions to 1 so that
only one per page can be made
Then when 1 back button is hit nothing is read back in. only when 2 times it
is hit something needs to be read in
And we hold much less in mem and save much less to disk. Its a simple
optimization that only has a win/win side.
I think we only should do this when it is really shown as a bottleneck!
Typically I would go for the premature optimization argument. But in
this case the penalty is pretty obvious and easy to measure.
Then i first want to see it as a hostpot in yourkit.
I will setup something.
The solution i propose and like is because of 2 things, the first one is
> minor
> 1> that we save much less, just the page at that time.. not the complete
> version history.
> 2> That the page in mem is much smaller again not the complete history
> (because that is already on disk)
>
> especially the last point is nice to have.. the drawback is when the
> backbutton is used the page will always
> come from disk. Which is now not the case because most of the time the
page
> can construct is previous page itself in mem.
That doesn't have to be the case, as we don't have to write
immediately. We could have an overflow mechanism with a combined rule
so that it doesn't write until we have say 5 versions when it has
enough available memory. I starting to think whether it wouldn't be
But where is the page being kept if it is not the active page?
When a page is not the active page anymore it has to be saved.
So you can't say no you only have to cache it.
And 5 page versions of the page as the active page is a waste. That eats
session space
that is not really needed because it is already cached.
We should strive for reducing session usage and that means only holding the
active page
and as low number of versions in the version manager.
Of course we could extract the version manager completely from the page and
make it a single
session thing for all the pages that has change sets for pages and that one
also saves those
to the FileStore of the SecondLevelPageMap (so the VersionManager is another
kind of second level cache
or we merge those 2)
That would be an option.
So that we only save a page when it falls out of the PageMap (not active
anymore)
and for the rest the "global" version manager will save the changesets.
And the page doesn't have a hard (not transient) reference to it anymore.
better to use an actual cache manager for this - like EHCache - so
that we don't have to write this ourselves and have something that is
easy to configure and stuff.
I don't see the real value in this at all.
It only complicates things and we get much to much garbage again for what is
now a few lines of code.
And it wont solve anything because Page and versions of it is now a single
object that also then is a single object.
Furthermore, you are right that most of the time we don't get it from
disk now, but the price (up till yesterday something I didn't notice
tbh) is that all those changes will stay in memory! And worse, the
page grows larger and larger, but is still saved as a whole on every
request. And again, we should optimize the writing, not the reading.
yes i agree. We should do something about the version manager in the page\
johan
